Use Xwt for dialogs in Gtk Pipeline

[harry-cpp]

I was thinking that in Pipeline tools open/save file dialogs don't look native on OS X, so why don't we just use Xwt for those dialogs.

@dellis1972 Thoughts?

[harry-cpp]

Actually maybe http://stackoverflow.com/questions/33341914/gtk-file-chooser-non-native-look-on-osx is better.

[CallumDev]

Remember MonoMac is 32-bit only, and Xamarin.Mac requires licensing from Xamarin to use.

[KonajuGames]

For all those OS X file open/save dialog options, it seems to be pick-the-least-worst. I do think native is better for file open/save dialogs, no matter the platform, especially on platforms that have native dialogs.

[tomspilman]

I do think native is better for file open/save dialogs, no matter the platform

Agreed... people expect file dialogs to look like what their native platform provides.

[harry-cpp]

I just realized something even better, we could use Xwt or Eto.Forms for all dialogs, that is replace dialogs in: https://github.com/mono/MonoGame/tree/develop/Tools/Pipeline/Gtk/Dialogs and https://github.com/mono/MonoGame/tree/develop/Tools/Pipeline/Windows with one set of them.

This would have 2 advantages:

1. WinForms Pipeline and Gtk Pipeline would share the same dialogs
2. Dialogs on Mac would be able to look native

[tomspilman]

we could use Xwt or Eto.Forms for all dialogs

Designing dialogs once and having them apply to all platforms has great benefits in code maintenance, documentation, and testing... this is why I think this is worth considering.

That said... I am concerned about two things:

1. The results won't feel 100% native on Windows.
2. There will be WinForm features we want to use that we can't.

As long as things feel 100% native on Windows and we're not too limited in getting the results we want... I can live with this.

Off a first glance I would say Eto.Forms is better because it supports WinForms, WPF, and WinRT support coming... giving us more options in the future.

We could start with an experiment in dialogs and see how it goes.

[harry-cpp]

I did do a xwt port of Pipeline Tool as a proof of concept a while back: https://github.com/cra0zy/MonoGame/tree/xwt

So I have all the xwt dialogs mostly done:
https://github.com/cra0zy/MonoGame/tree/xwt/Tools/Pipeline/Xwt/Dialogs

Tho I don't mind writing them with Eto.Forms.

[tomspilman]

did do a xwt port of Pipeline Tool as a proof of concept a while back:

I'll see if I can find time to take a closer look at that if anything just to check the XWT support.

My concern with converting everything over to Eto or XWT is that tricky things like tree views and property grids being impossible or just really crappy.

Tho I don't mind writing them with Eto.Forms.

I don't see XWT suddenly supporting Win10 Apps, but Eto seems to be doing that. So it seems like a better choice to me still.

How is the API in comparison?

Thinking about unit testing here... are there helpers for finding controls by identifier? What about APIs for programmatically clicking buttons or sending events to controls?

[harry-cpp]

I'll see if I can find time to take a closer look at that if anything just to check the XWT support.

My concern with converting everything over to Eto or XWT is that tricky things like tree views and property grids being impossible or just really crappy.

For the main window it's crappy, xwt doesn't support menu accelerators, toolbar, and anything good for propertyview.

Eto forms doesn't support drag and drop and has a major bug with treeview (picoe/Eto#451).

My idea is just to use it for dialogs because of above.

How is the API in comparison?

Eto.Forms is much much better, it supports everything I said was bad about xwt above, plus GUI previewer for both VS and MD, NuGet packages, and a very nice way of customizing native controls (picoe/Eto#449).

Also Eto.Forms is based from WinForms / WPF, while Xwt is based from Gtk, so you might like it even more.

Thinking about unit testing here... are there helpers for finding controls by identifier? What about APIs for programmatically clicking buttons or sending events to controls?

We would still have to write our own...

[tomspilman]

and a very nice way of customizing native controls (picoe/Eto#449).

That is a cool feature... I like that over being locked in to a lowest common denominator result.

[harry-cpp]

Well this code was badly written and crashed with Eto PCL dll in the folder: https://github.com/mono/MonoGame/blob/develop/Tools/Pipeline/Common/PipelineTypes.cs#L411

Excluding some stuff made Gtk Pipeline start faster :)

[harry-cpp]

Actually even better, we just need to load MonoGame.Content.Pipeline, that means that Win Pipeline should also get a bit of speed.

[harry-cpp]

Closing since the Pipeline Tool now uses Eto.Forms.