Upgrade to gtk4

[kaixoo]

• Upgrades all modules to gtk4
• Migrates code to gtk4 APIs.
• Improves performance of code editor (which now runs async).
• Run other things (i.e. file treeview) async

TODO:

• Migrate Gdk.Event*
• Migrate Gtk.SelectionData

[kaixoo]

I am getting this error and I don't know how to fix it:

error: Package `libpeas-2' not found in specified Vala API directories or GObject-Introspection GIR directories
Compilation failed: 1 error(s), 0 warning(s)
[3/146] Merging translations for data/io.elementary.code.policy
FAILED: data/io.elementary.code.policy
/usr/bin/meson --internal msgfmthelper --msgfmt=/usr/bin/msgfmt data/io.elementary.code.policy.in data/io.elementary.code.policy xml /home/aitor/Bureau/code/po/extra
/usr/bin/msgfmt: Impossible de localiser les règles ITS pour data/io.elementary.code.policy.in
ninja: build stopped: subcommand failed.

Since libpeas-2 doesn't rely on gtk anymore, should we remove libpeas-gtk-1.0?

[jeremypw]

I've changed this to "draft" status as it will take more than changing the dependencies to port to Gtk4. Some code changes will be needed too. A lot of things were removed or changed between Gtk3 and Gtk4 (see https://docs.gtk.org/gtk4/migrating-3to4.html) Thanks for making a start though! I'll look into the libpeas issue and get back to you.

[jeremypw]

It seems just about only Code uses libpeas amongst the Elementary projects. Files has similar plugins but just uses gmodule-2.0 as a dependency. Maybe worth taking a look at how Files does it? I already did a Gtk4 port of Files including two of the plugins (it was too big to review!).

Taking this into account the best strategy for managing the migration is to identify what needs to be changed and as far as possible make incremental changes as separate PRs to the Gtk3 version that will minimize the diff when the port is actually done.

[jeremypw]

Again, in the interest of small diffs, do not attempt to make unnecessary changes to the code while porting even if it could be improved. The first Gtk4 version should be as similar as possible to the Gtk3 version both in appearance and behaviour. After the port lands then we can set about incrementally taking advantage of Gtk4 features.

[kaixoo]

Improving the performance of the code editor is a consubstantial side effect of the gtk4 migration as APIs have gotten better (async). But thanks for the tip anyway! I agree that PRs should be kept reasonable

[jeremypw]

The relevant code in Files for the plugin system is:
https://github.com/elementary/files/blob/7897a150e1e52cabd427cf95324aa47255d8cffc/meson.build#L46
https://github.com/elementary/files/blob/main/libcore/PluginManager.vala
https://github.com/elementary/files/blob/main/libcore/Plugin.vala

as well as the "plugin.vala" files in individual plugins in the plugin folder. e.g.
https://github.com/elementary/files/blob/main/plugins/pantheon-files-trash/plugin.vala

[kaixoo]

I removed libpeas, upgraded all libraries, but there is still some package that's using gtk3 and conflicting:

gtk4.vapi:15949.2-15949.46: error: `Gtk' already contains a definition for `tree_row_reference_deleted'

[jeremypw]

I have raised a new issue re libpeas so that a separate PR can be proposed fixing it. See #1498

[jeremypw]

I removed libpeas, upgraded all libraries, but there is still some package that's using gtk3 and conflicting:

gtk4.vapi:15949.2-15949.46: error: `Gtk' already contains a definition for `tree_row_reference_deleted'

I'll pull your code and look into it.

[jeremypw]

The culprit is the vte dependency. It should be vte_dep = dependency('vte-2.91-gtk4', version: '>=0.76') See the draft Gtk4 port of Terminal. elementary/terminal#780

[kaixoo]

Fixed, but how did you know that was the version you have to upgrade to? I looked for "vte github", "vte vala", "vte gtk4 migration", etc.

[jeremypw]

If you search in Google for "vte 2.91 gtk4" its the first thing to come up. Or you can do apt search vte | grep gtk4 at the commandline to see what the required package is.

[kaixoo]

In C++ you could soft migrate to gtk4 while still using gtk3 widgets. I see you can't do that in Vala.

[jeremypw]

In C++ you could soft migrate to gtk4 while still using gtk3 widgets. I see you can't do that in Vala.

Probably to do with namespacing. There are many widgets with the same name in both libraries within the same Gtk namespace. If you shipped a modified .vapi file and re-namespaced the Gtk3 widgets it might work.

[jeremypw]

Migrating the menus is something that can be split out and done in Gtk3

[kaixoo]

Migrating the menus is something that can be split out and done in Gtk3

Nah, don't worry. It's easy to do. I can slice the PR in parts and explain all the changes here if you want.

[kaixoo]

I guess that can be left until after the port though if you are keen to press on with it. I do not want to discourage someone willing to contribute! It is great to have someone eager to attempt significant changes.

There needs to be people who are not egocentrical and help sustain this fantastical OS! But press me however you want, you won't discourage me :)

Also, I would like to bring as many of the plugins as possible into the main code as we do not support third-party plugins anyway and I am not sure what other advantages there are when memory footprint is no longer an issue.

Plugins are fantastical, they help keep the main codebase tiny and organized! Plus, some marginal features (for instance Vim support) can be added without adding weight to the maintainers of the main product.

Remember, writing code is easy - getting it reviewed, tested and approved for merging is hard.

Making the changes itself is hard enough >:L

[kaixoo]

libpeas-2.0 depends solely on glib, maybe it'd be easier to upgrade to it first? And remove libpeas-gtk-1.0

[jeremypw]

Plugins are fantastical, they help keep the main codebase tiny and organized!

True, but they also have drawbacks e.g. they only work when installed so you have to remember to do a sudo ninja install when developing to see the effect of changes. The interface with the main code is more restricted e.g. they cannot use actions.

I am not sure that code organization is a big deal - the symbol pane was migrated into main code from a plugin and now just reside in its own folder under /src rather than under /plugins.

However, you are probably right that specialist use plugins are best kept as such. I am talking about things that are commonly in use for a code editor.

[kaixoo]

I agree, things like looking for a file in the Sidebar would be better off in the main code. Let's work on that after the port!

[kaixoo]

meson can't find libpeas-2-dev dependency. Tried: libpeas-2, libpeas-2.0, Peas-2, Peas-2.0.

Available here in Valadoc: https://valadoc.org/libpeas-2/index.htm

[lenemter]

@kaixoo it's libpeas-2. Make sure you installed the dependency before building the project

[kaixoo]

I did sudo apt install libpeas-2-dev && rm build -rf. Same issue.

[jeremypw]

libpeas-2.0 depends solely on glib, maybe it'd be easier to upgrade to it first? And remove libpeas-gtk-1.0

Agree. I am looking into it now. Need to ship a .vapi file atm as the version in EOS8 does not include it.

[jeremypw]

I have pushed a working draft of (Gtk3) migration of Code to libpeas-2. See #1501. Work to migrate this to Gtk4 over and above migrating the plugins themselves should be minimal. Note this branch will only compile on EOS8 so we cannot make another OS7.1 release once this is merged.

[kaixoo]

libpeas-2 depends on glib >= 2.74, so gtk4. All the changes in this PR are ready I believe?

[leonardo-lemos]

Can you please edit CI and Flatpak files to include the new dependencies?

[kaixoo]

Is there something missing here? bb33ca5

[kaixoo]

I couldn't find any info on how to migrate Gdk.Event*s and Gtk.SelectionData

[jeremypw]

Is there something missing here? bb33ca5

Looks like libgit2-glib-1.0-dev is missing

[jeremypw]

I couldn't find any info on how to migrate Gdk.Event*s and Gtk.SelectionData

Event handling is mostly done by addingGtk.EventController* s of one kind or another and listening to their signals. Much of it can be done in preparation of the port in the Gtk3 branch,. Drag and Drop is handled by Gtk.DragSource, DragTarget and Gtk.EventControllerMotionDrop. See https://docs.gtk.org/gtk4/drag-and-drop.html. You don't need Gtk.SelectionData any more. This needs to be done during the port as there are no equivalents in Gtk3.

You can see how I did it in Files at elementary/files#2082 but that branch is now redundant and not necessary the best example.

[kaixoo]

Okay, I will be implementing all changes tomorrow

[kaixoo]

I don't know how to migrate Gtk.SelectionData in Widgets/SourceList/SourceList.vala. All other changes depend on #1502 and the gtk4 port preparation changes PR (Gtk.EventController). After it's done, we can compare if there's a performance difference between gtk3 and gtk4.

[jeremypw]

I've now succeeded in getting libpeas-2 to work in a flatpak (on OS8). So I am not sure whether it is best to keep libpeas for now as the PR is far less invasive. I'll have a look at this PR and try to create a branch that uses libpeas2. I'll also look into the SourceList problem. Maybe there is an alternative Gtk4 widget we could adopt? The trouble is a lot of Gtk4 widgets are sealed so difficult to customize so it would be best to keep the shipped SourceList until after the port.

[jeremypw]

One thing that occurred to me about plugins in general is that afaik it is not possible to ship a separate flatpak containing extra plugins even if we wanted too which negates one of their advantages.

[kaixoo]

One thing that occurred to me about plugins in general is that afaik it is not possible to ship a separate flatpak containing extra plugins even if we wanted too which negates one of their advantages.

If plugins cause more headaches than solutions, then fine, remove them. But VSCode does extensions fine in its flatpak version.

[leonardo-lemos]

I've now succeeded in getting libpeas-2 to work in a flatpak (on OS8). So I am not sure whether it is best to keep libpeas for now as the PR is far less invasive. I'll have a look at this PR and try to create a branch that uses libpeas2. I'll also look into the SourceList problem. Maybe there is an alternative Gtk4 widget we could adopt? The trouble is a lot of Gtk4 widgets are sealed so difficult to customize so it would be best to keep the shipped SourceList until after the port.

I think we should keep libpeas for now to focus on the Gtk4 port.

[jeremypw]

@leonardo-lemos Yes, I was coming to that conclusion. I have closed the other PR for now.

Problem solved