Port to GTK4

[davidmhewitt]

Opening for visibility. Not even close to finished or working.

This currently targets a granite-7 branch which just tracks master for now. Once we're happy with this, we can set up packaging correctly and have two versions of Granite install alongside each other so apps can target either while they're porting to GTK4.

Things to port:

• DatePicker
• ModeButton
• ModeSwitch
• SwitchModelButton
• TimePicker
• ValidatedEntry
• HyperTextView
• Dialog
• MessageDialog
• DynamicNotebook (could in theory be deprecated and replaced by the Hdy widget?)
• OverlayBar
• SourceList
• StorageBar
• WelcomeView
• SeekBar
• AsyncImage

Known Regressions:

• DatePicker and TimePicker popovers don't work because you can't (easily?) attach a popover to a Gtk.Entry
• Need to figure out classes/styling for SwitchModelButton
• Need to figure out how to pack AccelLabels as "menu items" in the AccelLabel demo popover.
• Need to fix Granite.Widgets.Utils.set_color_primary
• HeaderLabel was dropped as GtkLabel is sealed, so it's not easy to subclass, so we have all these labels we now have to add the extra properties and style classes too, is there an alternative?
• HyperTextView doesn't always reliably detect CTRL key press, haven't tested this on master to see if this is actually a regression
• HyperTextView no longer spawns error dialog as I haven't ported MessageDialog yet.
• Dynamic margin stuff in MessageDialog is commented out for now, should this be done in the stylesheet?
• Nasty get_parent ().get_parent ().get_parent () in DynamicNotebook
• I removed the context menus from DynamicNotebook for now
• DynamicNotebook may be broken in many ways

[danirabbit]

Something I was thinking about is if we should take this opportunity to only port things one at a time as we need them and rethink some old APIs.

Some of the old APIs make it a pain to assign actions to widgets. For example, I really hate the Welcome page API. I also wonder if ModeButton can't be replaced with a style class for Gtk.RadioButton?

[davidmhewitt]

@danrabbit Do as you wish 🙂

I'm just doing a naive port for now and trying to keep the API as consistent as possible. I'm most of the way through now, so I've already sunk the effort on porting stuff that may get thrown away later, which is fine as we can at least mark it as deprecated for a while first. I already threw out a bunch of stuff that was already marked as deprecated.

As for fixing API, that's fine too. I'm just trying to get the thing to build and be mostly feature complete. We don't have to offer any guarantees of API stability just yet.

[treppenwitz03]

Greetings @davidmhewitt! I see that there will be api changes, like for example the Welcome widget. I got a bit excited so I tried to make a proposal for the new welcome api, which I think is much simpler and more spot-on. Feel free to tell me what you think :). This is the link https://github.com/ZenitsuDev/new-welcome-design-proposal

[davidmhewitt]

@danrabbit This should now happily install alongside the existing version of Granite. If you're happy with how this currently is (missing widgets and known regressions as above), then I would suggest merging this into the granite-7 branch as proposed and we can set up some packaging against that branch.

[danirabbit]

Let's do it! 🚀