Support GTK4 exclusively and dismiss GTK3 support

[badcel]

Todo:

• [x] Fix Compilation problems which do not depend on gir files (part of #545)
• [x] Enable building GTK4 (see #542)
• [x] Depends on #541 as current gir files (fedora 35) are not error free.
• [x] Add Interfaces to type hierarchy. (Required for about dialog sample, #582)
• [x] Update Samples to use GTK4
• [x] Update Tests to use GTK4
• [x] Remove GTK3 / GDK3
• [x] Remove workaround code for GTK3 / GDK3 (see below)

---

There are legacy constructs in GTK3 which make our code ugly. As there is GTKSharp for Gtk3 we can just be the follow up library for GTK4.

This takes the burden of maintaining several libraries, which got obsolete with the introduction of GTK4 and we do not have to care about "legacy" libraries.

Remove the code which is only there to support GTK3. It should be marked with a TODO and a hint regarding GTK3/Gtk4.

Current workarounds:

• "Secret Factory method" for GDK Event (BoxedWrapper.cs)
• module_type_registration.sbntxt contains try catch clauses because there are some classes inside GTK3 which are not available on all platforms.
• Workaround for unresolveable property setter annotations see method ResolveMethodReference in AccessorResolver and the corresponding generators.
• Workaround property Method in Class MethodReference use GetMethod instead

[mikkeljohnsen]

I think it would be a good idea, to target Gtk4 only.

[gavr123456789]

Fully agree, GTK 4 + LibAdwaita https://github.com/gircore/gir.core/issues/375
Also there will be new demo app on GTK 4 + LibAdwaita that demonstrates all common GNOME HIG patterns https://twitter.com/allanday/status/1422844120855457793
https://gitlab.gnome.org/exalm/patterns

[mjakeman]

Also there will be new demo app on GTK 4 + LibAdwaita that demonstrates all common GNOME HIG patterns

Since LibAdwaita is going to be GNOME's platform library, I would be interested in porting over Patterns to act as a demo of sorts (once we support GTK 4/libadwaita of course). It's thankfully very simple by design and also MIT-licensed which removes the licensing issue of copying GTK's demos.

It could be a nice 'replacement' for the old GtkApp sample (#395)

[badcel]

If we remove GTK3 we would need to skip WebKitTGTK as long as it is not ported to GTK4.

[mikkeljohnsen]

Webkit2Gtk is not working on Windows. (and WebkitGtk is very old). So CEF should be supported instead. But CEF has no gir I think.

[badcel]

@mikkeljohnsen We already had some proof of concept support for WebKit2 and Gtk3. It just got removed during rewrites as it added additional work to keep it running. I want to restore this functionality as it is probably a quite common requirement. But it conflicts with the removal of GTK3.

The gir file is here: https://github.com/gircore/gir-files/blob/master/WebKit2-4.0.gir The original sample code is here: https://github.com/gircore/gir.core/blob/b5558be8cba01f40503f5e3c280d6dd85fc7ba57/Samples/Gtk3/GtkApp/MyWindow.cs

It did inject a javascript method into the DOM and bound it to a given HTML button. On click C# received a callback from the javascript world and read a property from the transfered javascript object. This was quite fascinating to see working. I don't know of any other C# library supporting this.

This feature is mentioned on the homepage, too: https://gircore.github.io/docs/libraries.html#webkitgtk

Edit: I actually only tested it with linux. I don't know if it was working for windows.

[badcel]

I'm sorry to say that as long as there is no CEF GIR available it is out of scope for this project. Perhaps it is possible to integrate it somehow into a GTK based application but this would be another project's task.

[darkdragon-001]

For everyone else wondering:

CEF = Chromium Embedded Framework

[darkdragon-001]

Webkit seems to support GTK4 now though: https://discourse.gnome.org/t/webkit-support-for-gtk4/8061