Eto is a dying project unfortunately, there has been very little activity this year. Unfortunately, GTK# is in a similar state though it is being used by several large open-source apps and it is directly under the Mono umbrella. All that said, I agree with the idea that an app with Win/Mac/Lin support will need to use a non-Winforms UI library to ensure a high quality app.

I got the impression that GTK# wasn't doing a great job with OSX?

Well, you're right in that it doesn't provide a "native" visual experience, bug-wise I don't have any information, and it should be feature-complete across all three platforms (Mono GTK# explicitly supports OSX)

Ultimately to really do things right on each platform, we'd need to refactor the entire Data <-> UI and create a new layer which would allow per-platform UI code to run. Not a bad idea imo, but a lot of work and it's best to have a clean base before starting something like that.

I'd be happy with a somewhat imperfect UI that works across all platforms. No one's paying for CKAN, after all.

Seconding GTK# as a solution. Not only would provide a much better experience across all non-Windows platforms, GTK+ is a mature and well-supported framework. So unlike using another mono-specific solution, there is little risk of future abandonment.

Notably, there is also a potential to build an app bundle which contains all of CKAN's dependencies. That would eliminate the need to install mono, or to use the command line at all. Though I'm not sure whether or not gtk-mac-bundler works with GTK#.

edit: actually, sounds like monomac development has moved to Xamarin, which provides free and commercial licenses for:

Xamarin.Mac is a new foundation for building Cocoa applications on OSX using Mono.

Details about Xamarin.Mac are covered at http://xamarin.com/mac

What about using MonoMac.Windows.Forms?

"Monomac.Windows.Forms is a project to allow users to reuse 90% of winform code designed on windows to produce an equivalent application for a mac with a native Cocoa UI. (Even Designer generated code!)"

#1011 is another related issue

What about Qt? It seems to be more future proof, is truely multi-platform, and supposedly it is easier and more efficient to work with.

Mono bindings are available at https://github.com/ddobrev/QtSharp

Just an aside, I was/am wrong about Eto, for now it seems to be progressing. It solves the problem of running UI code on different platforms pretty well, but it does expect you to fill in, for example, multiple event handlers to deal with WinForms, OSX, and "Mono on non-OSX platforms" i.e. Linux.

Qt would likely require small amounts of Mac-specific code in the same general way we have to include Platform.IsMac now. If some users could comment on the examples provided here - we need to decide if their interpretation works well enough to resolve the incongruities we are observing now (bye bye libgdiplus.dylib) and would at the same time open the door for new possible messes with libqt and its cadre of related object files. I don't know how stable those libraries are in Macworld but welcome peoples' two cents.

Also, Qt is its own tongue in the same way that WinForms is - I still think it's a very good library, but we will need to start looking for a lot more knowledge in that realm. Last time I worked with it was around 4.8... little bit rusty.

One reason I'd suggest GTK+ over QT is that its bindings are officially maintained, rather than an outside project. GTK+ also seems to have strong support in MonoDevelop (providing the ability to visually design the interface), but I'm not sure about QT.

Yeah, Qt wants you to use their form designer/IDElet, but they do ultimately support VS debugging and do not integrate well with MonoDevelop. I wish I could lobby for MonoDevelop but I just don't care now that VS is free - MonoDevelop has been clunky and limited at its best in my personal experience. GTK# supports VS debugging nowadays, but Stetic (the MonoDevelop GTK# form designer) does not have a VS parallel that I am aware of.

Hi,
I have checked some possibilities to use GTK#3 to create cross platform user interface. Long story short: I was unable to run it on MacOSX, so it is not cross-platform. The cause of it, as I believe, is that C# wrapper for GTK3 is written only for 32-bit version of library, but GTK3 is available for MacOSX only for 64 bits. It is possible that GTK2 does not have such problems but it would require separate Proove Of Concept.

The source code for the test can be found here: https://github.com/grzegrzk/CKAN/tree/feature/gui-gtk/GUI-gtk

Below are some details that may help somebody in investigation to try to use GTK#2 instead.

GTK has its interface designer – glade. It is pretty nice to work with besides having some idiosyncrasies. I have designed in it limited set of pages from original CKAN:

The produced .glade files can be used to run the application:

I have integrated displaying list of mods and it works nicely when run on windows. The performance is a little bit worse than Windows Forms, but I think it is nothing that users would be concerned about.

The main problem I have encountered is lack of documentation - how to start, which library I should use, what to install and what functions to call to initialize GTK# was a little mystery, also I had some problems to display icons & arrows but almost all of it was solvable.

The problem I was unable to solve is how to run it on MacOSX. Firstly I thought it is because author of “GtkSharp” package does not support MacOSX (the library dependencies are wrong). The dependencies can be displayed using:

find . -iname "*.config" -exec grep dll {} +

They can be replaced using some bash magic (WARNING! Do NOT run this script anywhere else CKAN folder or it may destroy your files! Run it on your own responsibility!):

find . -iname "*.config" -exec sed -i '' -e 's/lib\([^ a]*\).so.0/lib\1.dylib/g' {} +

But the main problem is that libgtk-3.dylib is only for 64 bit systems:

$ locate libgtk-3.dylib | xargs file
/usr/local/Cellar/gtk+3/3.18.2_1/lib/libgtk-3.dylib: Mach-O 64-bit dynamically linked shared library x86_64
/usr/local/lib/libgtk-3.dylib:                       Mach-O 64-bit dynamically linked shared library x86_64

So I cannot run it using standard “mono”. When I try to run it using “mono64” I get some exceptions from inside native GTK libraries – I believe it is because C# wrapper is written only for 32-bit library, but GTK3 is available for MacOSX only for 64 bits. I do not know how to solve it:

$ mono64 GUI-gtk/bin/Debug/ckan-gtk.exe
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands
CKAN.Properties.Resources.resources,CKAN.resources.ckan-gtk-glade.glade,CKAN.resources.apply.png,CKAN.resources.backward.png,CKAN.resources.forward.png,CKAN.resources.ksp.png,CKAN.resources.refresh.png,CKAN.resources.search.png,CKAN.resources.settings.png,CKAN.resources.textClear.png,CKAN.resources.update.png
2017-01-29 12:55:42.753 mono64[28952:4540049] *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead. 

(ckan-gtk:28952): GLib-CRITICAL **: void g_datalist_id_set_data_full(GData **, GQuark, gpointer, GDestroyNotify): assertion `key_id > 0' failed

Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object
  at CKAN.Program.Main (System.String[] args) [0x00034] in <437eb93efe9d4ad5b418f849def37952>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object
  at CKAN.Program.Main (System.String[] args) [0x00034] in <437eb93efe9d4ad5b418f849def37952>:0 

One option to workaround it would be to use GTK#2 instead. I did not try to run it on OSX but I think there is greater chance it will work.

When I tried to run GTK#2 on Windows I succeeded, but the main problem is that GTK2 is not compatible with new versions of Glade interface designer. Old Glade designer would be needed (I was unable to find download for it anywhere on the net, but I have read it should work) or it would require post-processing .xml files produced by new Glade Designer to make .glade files compatible with old GTK2. All in all I lost faith a little bit in this whole idea so I did not try it.

As you can see I cannot advise any solution to the problem of cross-platform GUI except that GTK3 may be not a good option until authors solve problems with running it on MacOSX. I have seen in some comments above ideas to create separate code base for each platform but I do not believe it is possible for open source project in the long run. When I was contributing to CKAN I had problems with contribution to separate CLI interface, so separate GUI for each system would probably prevent anybody from contribution.

The next thing to consider, in my opinion, would be to try out GTK2 (risky because this is old library so the updates may be infrequent) or Eto (risky because there is no big organization behind it, isn't it?) or to try to find some different solution.

BR,
Grzegorz

http://www.mono-project.com/docs/gui/gtksharp/ seems the best location for documentation. There certainly seems to be an intention to support MacOS, so maybe it's worth putting in a bug report?

https://mono-project.com/docs/gtksharp seems the best location for documentation. There certainly seems to be an intention to support MacOS, so maybe it's worth putting in a bug report?

The mentioned address does not work, I believe the valid one is this one.

The release plan page mentions that the supported GTK right now is GTK2 and they are planning to switch to GTK3. I cannot see any information when it may happen, though. The page says:

As the Gtk+ 2.14, 2.16 and 2.18 releases did not add any significant API except of GIO, we decided to focus on creating bindings for Gtk+ 3. Currently, trunk still targets Gtk+ 2.14, but we will switch to version 3 as soon as it is usable.

Edit:
And as I mentioned I had problems with GTK2 because I was unable to use Glade designer with it, that is why I did not play with it longer.

Thanks for your investigations. It sounds like they may be somewhat disorganised.

It's weird that I can't much discussion of GTK#3. There is at least one unofficial NuGet package which appears to be maintained, but I have no idea how reliable (or even compatible) any of this is.

Small update:

Starting with macOS 10.13.4 a warning message is displayed when 32-bit applications are launched for the first time. It's generally believed that 32-bit apps will still be supported in macOS 10.14, but we won't know for sure until WWDC, which starts on June 4th.

There doesn't seem to be much interest in porting Mono's remaining bits of Carbon to Cocoa, so the days may be numbered for WinForms on macOS.

For anyone working on this issue and want to use Glade: You'll need to find a copy of version 3.8, as newer versions (3.10+) only support GTK+3.

See #2272 for the problem of MacOSX 32 bit support.

At least we'll have consoleui as a Mac lifeboat should the situation on that OS continue to worsen.

MAUI is probably the better choice than GTK# at this point. Supposedly it will be supported by the core .NET project, on all platforms.

https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/

MAUI is still pretty far off, not sure if anyone has heard of it before but AvaloniaUI is a pretty decent cross-platform UI solution for .NET Core.

@FramnkRulez MAUI has the advantage of being part of .NET, rather than an external dependency with unknown support down the road.

Microsoft has just announced that MAUI won't be cross-platform after all; Linux won't be supported 😭 :

• https://devblogs.microsoft.com/dotnet/announcing-net-6-preview-1/

.NET 6 Preview 1 introduces the first two platforms of .NET Multi-platform App UI: Android and iOS. .NET 6 sample mobile projects and installation instructions will help you get started building Android and iOS apps. Future previews will add support for macOS and Windows desktop,

• First class Linux support developed by Microsoft dotnet/maui#339 (comment)

Linux support in .NET 6 for .NET MAUI is not planned from us. We are spending our capacity bringing the Xamarin stack to .NET 6, SDK Style projects, and, as has been noted elsewhere in this thread, addressing fundamentals in the UI toolkit. I hear that saying "it's on the community to add Linux support" can sting and disappoint. In this .NET 6 phase of the product it's the current way forward, and to not keep the door open to the possibility of collaboration would send a very different signal.

The signal here is meant to be that Linux is a platform on our radar, it is not part of our current scope of work for .NET 6, and we are open to collaboration in the meantime.

This is a pretty big disappointment for CKAN; we were looking forward to moving to a new GUI framework, but we can't just drop a whole platform that works today.

So is the GUI framework gonna be GTK# since MAUI isn't cross-platform?

MAUI won’t officially support Linux but there may be community support for it. Barring that it might be a good idea to look into something like Electron with callbacks to .NET 5 or Avaloniaui.

Is this still actively being worked on? I had thought to try to port the UI to Tk, but I don't want to be redundant with others' work.