Port Panel to GTK4

[danirabbit]

[davidmhewitt]

I would say that this is the most important port for OS 7 (along with all of the indicators). Because all of the indicators will have to be ported to GTK4 and released at the same time, it's probably better to do that during the development cycle and ensure it's reasonably well tested.

Porting and releasing a desktop app after release is one thing, but a significant part of the shell, that all has to be released at once is probably a bit more tricky and dangerous.

[danirabbit]

I'm thinking this probably makes sense to punt to OS 8 since it's such a big port. That would also be a good time to think about a larger redesign if we want to do responsive/mobile. Two big things I think to consider are:

Should we drop the plug-in system? We don't have any way to distribute plugins in AppCenter and afaik there aren't any distros or OEMs shipping anything besides the default indicators. This is also a potential point of failure since extensions run in process.

Should we consider some kind of quick settings menu design like GNOME, Mac OS, Windows 11, etc? This would make it a lot easier to do responsive/mobile and it might make it easier to do transient indicators like night light and privacy indicators

[davidmhewitt]

I'm thinking this probably makes sense to punt to OS 8 since it's such a big port.

I don't think it would take that long to port wingpanel to GTK4, other than the applications menu and the datetime indicator, everything is very templated and standard widgets, so it'd just be repeating the same port for the most part.

Should we drop the plug-in system? We don't have any way to distribute plugins in AppCenter and afaik there aren't any distros or OEMs shipping anything besides the default indicators. This is also a potential point of failure since extensions run in process.

I personally feel the modularity of Pantheon as a whole is one of its best strengths. Don't want a particular indicator taking up tray space or RAM? Just delete it. This means that packaging for other distros is easier. If there's a specific dependency that's unavailable, you can just drop that indicator instead of the whole panel. Plus, the code is nicely separated allowing for easy maintenance and testing of individual components.

Saying extensions run in process being a stability concern I think is a non-point. If we deleted the plugin system today and merged all the indicators in, it'd be just as stable/unstable. Sure, people could write a crashy extension currently, but you've just said people don't have a way of shipping it officially, so on the whole they don't 😅

[danirabbit]

Yeah that's fair. I've opened a new discussion regarding potential future designs. If you feel like porting the existing design this cycle is feasible, then I'm available to help!

[danirabbit]

It sounds like a blocker we have is that Adwaita doesn't have touchpad gestures for Deck/Carousel. So it might be better for now to just do lots of cleanup branches, port as much API as we can in Gtk 3 for now and then when we get those gestures or if we make our own Granite widgets for this purpose then finish the Gtk 4 port at that time