search

KSP-CKAN / CKAN

The Comprehensive Kerbal Archive Network
https://forum.kerbalspaceprogram.com/index.php?/topic/197082-*
Other
1.98k stars 347 forks source link

Move UI from Winforms to GTK# #1840

Open politas opened 8 years ago

politas commented 8 years ago

It seems we have many problems with our UI, especially on MacOSX. The Mono Winforms implementation is not being actively maintained, and there are many reports of limitations with its cross-platform capabilities and performance.

Eto.Forms looks to be a good replacement option. The latest release was last December, there are a small number of recently opened issues and recent activity on the GitHub.

Discussion has settled on GTK# as a better option. My own experiments shows it to be much easier to work with.

ayan4m1 commented 8 years ago

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.

politas commented 8 years ago

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

ayan4m1 commented 8 years ago

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)

ayan4m1 commented 8 years ago

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.

politas commented 8 years ago

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

rspeed commented 8 years ago

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#.

100ideas commented 8 years ago

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!)"

politas commented 8 years ago

1011 is another related issue

warptozero commented 7 years ago

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

ayan4m1 commented 7 years ago

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.

rspeed commented 7 years ago

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.

ayan4m1 commented 7 years ago

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.

grzegrzk commented 7 years ago

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:

obraz

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

obraz

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

politas commented 7 years ago

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?

grzegrzk commented 7 years ago

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.

politas commented 7 years ago

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

rspeed commented 7 years ago

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.

rspeed commented 6 years ago

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.

rspeed commented 6 years ago

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.

HebaruSan commented 6 years ago

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.

HebaruSan commented 4 years ago

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/

FramnkRulez commented 4 years ago

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.

rspeed commented 4 years ago

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

HebaruSan commented 3 years ago

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

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.

1Wyatt1 commented 3 years ago

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

FramnkRulez commented 3 years ago

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.

TV4Fun commented 2 years ago

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.