Port to Gtk4 and Gtk.SourceView5 #1510
Conversation
* feat: migrate DocumentView.vala drag-and-drop Replaced drag_received with drag_begin(Gtk.DragSource). Replaced Gtk.TargetEntry with GLib.Value * feat: migrate Sidebar.vala gtk drag-and-drop * feat: migrate MainWindow.vala Gtk.TargetEntry. TODO: Gdk.EventAny * feat: migrate Gtk.DragContext in SourceList.vala --------- Co-authored-by: kaixoo <21697330-kaixoo@users.noreply.gitlab.com>
* First compilable version * Emulate previous appearance of Plugins view * Update ci.yml * Update io.elementary.code.yml * Bump glib dependency for libpeas-2 * Rename non-functional Flatpak manifest * Sync checkbutton with plugin loaded on show * Action when checkbox toggled * Fix double parenting * Sort plugins by name * Use bind_model and factory * Lose unused entities * Cleanup and code style * Fix initial appearance of preferences dialog * Add some comments * Lose commented out code * Make activate and deactivate methods mandatory to implement * Fix Flatpak build for OS8 * Fix ci.yml * Add libgit2-glib-1.0-dev to ci.yml * Split SourceList into one file per class * Fix changed namespace * Remove DnD code * Replace Gdk.EventKey * Use GestureClick * Handle showing context menu * Handle search_entry focus in * Handle window close request
# Conflicts fixed: # src/Widgets/ChooseProjectButton.vala # src/Widgets/DocumentView.vala
|
@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! |
|
Need to check if any of this can be split out and merged pre-porting |
|
Does this mean that you plan on creating a separate |
That would seem easier but it really depends on what @danirabbit wants to do. |
|
Generally we've successfully done ports by:
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 🤷🏻♀️ elementary/files#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 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 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! |
No description provided.