Pipeline GUI Tool #2441
Pipeline GUI Tool #2441
Conversation
Removed IModel, controller talks directly to PipelineProject.
…andable for the processor to show sub elements.
-changed target framework from .net40 to .net45 -changed target platform from AnyCpu to AnyCpu Prefer 32-bit Note that we actually want MGCB to be x86 but it still has some dependences on native 3rd party assemblies which are x86. Pipeline Solution: Added MGCB project. Pipeline project: -added reference to MGCB project Pipeline needs this in the output directory in order to perform builds -changed target platform in debug configuration from AnyCpu to AnyCpu Prefer 32-bit Note this matches the release configuration plus allows edit and continue. ContentItem.Processor.cs: No functional changes, removing unused code and whitespace changes only.
Added property member type support for command line parser.
…ed assemblies. All processor properties are now visible even if they were not explicitly given a value in the file.
… the property grid.
Now showing correct properties for the current processor when the processor changes. Now only showing processors which can accept input of the type output by the current importer. When the importer changes such that the current processor is invalid we set the default processor for the new importer. Implemented project serialization.
…ew node. Added icons to treeview nodes.
…properties: References, OutputDir, IntermediateDir, Profile, Config, Platform.
It is a little more complex... but sort of. The value side of the property grid can be more than just text, could be text + button, a combobox, a check box, etc. Also you have expanding sections which can be rolled up to hide some nested grid items. If we get something working well it might be worth contributing it back to XWT. If they had a complete set of controls we could just use it across all platforms. |
|
Is Xamarin Studio using XWT? Is their property grid implementation available somewhere? |
|
Xamarin Studio uses GTK#, and their property grid is buried in the I had been thinking of dynamically generating a scrollable panel with a |
Xamarin uses XWT only for the Android Interface Designer.
XWT was created exactly with that in mind (http://foodformonkeys.blogspot.com.br/2012/11/xwt.html )
Another approach would be inject the Property Grid directly from the backends... For Linux we'll still need to unbury the component from the MonoDevelop source or implement it using other widgets... |
WinForms is the only one I know of that has a native property grid, but XWT |
|
So... the plan is:
Is that correct? |
|
That looks like the plan. I had started on the first two. It's not |
|
Please do, so I can help you. |
|
FYI @KonajuGames @thiagoabreu. Looks like Xamarin is moving away from XWT themselves... https://twitter.com/migueldeicaza/statuses/490307630208778242 Maybe you guys should follow their lead on this and use XamMac directly? |
|
The main problem isn't the toolkit itself as the only thing the GUI need is implement the IView interface and present output... The main struggle is the PropertyGrid that only WinForms have by default. The MonoDevelop version draws the grids directly in Cairo. We're still investigating how to make it work... We already have most of the GUI coded using only XWT which is fully reusable for Windows, Linux and Mac. And I think this way it will be easy to maintain the code on the long goal... But that's only my opinion. If you think going directly to Gtk/XamMac/WPF is better, I'm ok with that too... |
I'll be very happily surprised if the XWT version is better on Windows than the WinForms version. I fully expect that the XWT version will be for non-Windows machines only. That would be fine as there would be little code to maintain there.
That for sure helps... I just wanted to let you guys know about what Miguel and Xamarin are planning. |
|
The ATF project has a PropertyGrid - among other cool stuff. looks good. There's also one at the Extended WPF Toolkit. In my editor I use DenisVuyka https://github.com/DenisVuyka/WPG/wiki/Layouts |
|
Is there any update on this that will enable Linux developers to compile content with ease? |
|
@thiagoabreu @KonajuGames - What is the status on the Mac version of the tool? Did things get moving or do we need someone to jump on this? |
|
The Mac version can import a contentproj, load a mgcb, save the mgcb and The Linux version that @thiagoabreu was doing is at the same point I The Xwt UI toolkit appears to suffer the same problem that all |
Would it be difficult to at least get that work merged in? Or do you think it isn't ready for that? |
|
I can get that part merged in tonight. |
Agreed. I'm working on a port with GTK#. |
|
@tapir - Note that you do not have to build content on the platform you are targeting. Eg, you can run the PipelineTool on your PC and build content for your game targeting Linux. |
|
I'm aware. That's just very far away from ideal workflow when you're mainly
|
|
#2966 added as a WIP Pipeline GUI for Mac. |
|
Situation: Issue: Possible solution :
|
That is a problem that documentation should solve.
We don't want to clutter up the build log with that. |
|
I've been playing around with Xwt yesterday and today, and it's really good. Also it's naming scheme and the way everything works is similar to Gtk, so for someone like me it makes it very easy to use. |
Because it was originally designed by Xamarin to replace their usage of Gtk. However i've been told Xamarin are moving away from Xwt themselves... this is why we decided on Gtk. |
Even tho Xamarin decided to abandon it, the project itself is still quite active. Is the OS X Pipeline going to stick with Gtk, or are there some plans for Cocoa? |
Absolutely... the last thing we want is a 3rd GUI toolkit to maintain if we can avoid it. |
|
We started the Mac and Linux Pipeline Tool with Xwt but found it lacking in
features and documentation, and had a crash that we couldn't figure out at
that time. It also suffers the same affliction as most other cross platform
GUI toolkits: it just doesn't look or behave like a native application. On
Linux it is a wrapper around Gtk that has less features than Gtk. On Mac it
doesn't expose enough of Cocoa to implement everything we need in the tool.
|
Agreed on documentation, but... caugh https://github.com/cra0zy/MonoGame/tree/xwtpipeline caugh.... people do tell me that I am stubborn.... try it out. It's only Windows and Linux version, I don't own a Mac, so can't really build for it. The only thing I found missing feature wise are accels for MenuItems. Also I won't setup any PRs with it, I just built it to prove that Xwt was a viable way of doing it. |
This is the first commit of the Pipeline GUI tool for nice visual editing of the new MonoGame content pipeline command files. The tool looks like this:
It currently has the following basic features which makes it usable immediately:
It was built using C# and WinForms specifically for Windows support. We have a simplified MVC design intended to allow someone to eventually implement a new IView for MacOS and Linux.
Our next steps here are to get feedback from users, iterate on the core features, and improve the functionality. A few things on our roadmap for the tool:
Thanks to @jamesford42 for making all the treeview and property grid work correctly.