elementary
Port to Gtk4 and Gtk.SourceView5
@zeebok Thanks for the review. Its a while since I've thought about this. I've corrected that libsoup dependency in CI. I am not sure why this PR is not in draft as there is a lot of migration still to be done on it. I fear the diff is already too big anyway and changes need to be backported to the Gtk3 version where possible first.
@zeebok Thanks for the review. Its a while since I've thought about this. I've corrected that libsoup dependency in CI. I am not sure why this PR is not in draft as there is a lot of migration still to be done on it. I fear the diff is already too big anyway and changes need to be backported to the Gtk3 version where possible first.
That's fair. I am trying to make a swap at older PRs across the board, that I know are still relevant, and so here I am lol. The PR has a lot of files but a lot of them are small changes, so I am not sure if it is too big. But I trust you to do things in a smart way, just let me know when I should take a look!
Does this mean that you plan on creating a separate gtk4 or next branch that we can gradually push gtk4 changes to before finally merging to main?
Does this mean that you plan on creating a separate
gtk4ornextbranch that we can gradually push gtk4 changes to before finally merging tomain?
That would seem easier but it really depends on what @danirabbit wants to do.
Generally we've successfully done ports by:
- Creating a slop branch to identify issues preventing a GTK4 port
- Making smaller branches that contain refactors based on things we learned from the slop branch and merging those into main
- Updating the slop branch as we go until there's nothing left we can refactor in main and the diff is reasonably reviewable
So far we have not successfully merged in a branch that tries to do the GTK4 port all at once in a large branch. So I would not recommend doing it that way because it has never worked in the past
@danirabbit The ports done so far have been relatively small. I suspect the diff for Files will still be fairly large even when as much prep work as possible has been done. I am not sure what a "slop" branch is but if you can identify areas of prep work that can still be done in Files I am happy to do them.
I think I'd very much disagree that system setting was a small port 😅 But a lot of the final diffs got down into just a couple hundred lines because of spending time to make smaller more reviewable branches in preparation.
A slop branch is a branch that is just intended to be used to prove a concept. Like a sketch or a rough draft. It isn't necessarily intended to be merged, just to find out what it would take to complete the task.
For the Files port, I haven't looked at it in a while, but I listed a few things here. So far none of them are checked 🤷🏻♀️ https://github.com/elementary/files/issues/1941
But that's really what the purpose of a slop branch is, is to find out what things need to be done and then you can see how many of those things can be done in GTK3. Things like not subclassing classes that will become sealed, this can be done in individual branches before the final port. Making sure to split up margin into margin_top/end/bottom/side can be done in individual branches.
A complex Menu port can be broken down into making a branch to make GTK.menuitems backed by Glib.Action. Then following that up with a branch to build GTK.Menu with a GLib.MenuModel. And then in the final GTK4 branch it's just a couple lines to replace that with GTK.PopoverMenu instead of waiting to do the whole thing at once.
Almost any time we'll need to use EventControllers can be done in GTK3 in separate branches. Especially with regards to key controllers or multipress/click controllers.
Making the switch to using the child property instead of add can be done in GTK3.
There's a lot that can be done in individual branches :) and we can move fast on reviewing those if they're only a couple dozen lines and it's easier to catch mistakes like the one you caught with my Calendar branch. Something like that might go unnoticed if I tried to port Calendar all in a single branch
@danirabbit Do I understand correctly that when all that can be done in Gtk3 has been done (presumably you will determine that?), then you envisage a single PR that converts all remaining to functional Gtk4? If so, then I guess each commit to that needs to be logically separate like a mini-PR. I could try squash merging locally from local sub-branches to facilitate that.
But first you need to decide what is the higher priority to port - Terminal, Files, or Code. I already have draft working ports of Terminal and Files. I haven't done much on Code yet.
As the Terminal port is already less than 1000 lines, I suggest we concentrate on that one first. I'll push some small cleanup PRs.
@jeremypw yeah typically the final GTK4 porting PR ends up being a few hundred lines but they're almost all really easy to review syntax changes. Splitting things up into logical commits can definitely help for the more complex parts though!
I think the goal is just to get it down to something that you can reasonably say, "Yes I've read each line of this diff and am confident in what each change does and can sign off on it". So if you've got a class that just has like 3 lines of simple syntax changes then that's fine, nbd.
Yeah I remember the Terminal port being fairly close. That would be great to finish up. Thanks!