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

[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]

@jeremypw left to do:

• Migrate libpeas
• Migrate gtk Drag and Drop

I could get a hand with this. Let's be patient with the plugin system. If we are going to remake it, let's rethink it and make it asynchronous.

[jeremypw]

Nah, don't worry. It's easy to do.

It's to make it easier to test and review. Also when a PR is merged all its commits are squashed into one and cannot be individually reverted. I understand that it is easier for the author to do everything in one PR - I've often done it myself but had to break things into smaller pieces to get them reviewed. See how @danirabbit does things for an example.

[kaixoo]

Opened a PR here for the Drag-and-Drop changes: kaixoo#1

Invited you as a collaborator so you can make changes, approve the PR, etc.

I'll keep the gtk4-libpeas-migration as small as possible and then we can improve on the current plugin system.

[jeremypw]

What has happened in other elementary projects that have successfully migrated to Gtk4 is that as many changes as possible are made to the Gtk3 master branch. Then a new main branch has been created which is for Gtk4 code and becomes the focus of development. An exception is the Files project in which the main branch was created prematurely (the Gtk4 port I did was rejected as too large) so the main branch is still Gtk3.

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. 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. Hopefully in the not to distant future you will be approved for review in merging code and will be able to look at some of my PRs.

Try to resist making changes that are not strictly necessary for the Gtk4 port, tempting though it is. I made that mistake. I recommend to make incremental preparatory changes in Gtk3 and leave the improvements until after the port even though it may feel you are doing work that may soon be superceded.

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

[jeremypw]

The required drag and drop changes cannot be done in Gtk3 so have to be part of the Gtk4 port PR. You can certainly have separate PRs based on the main Gtk4 for separate consideration provided they are sufficiently self-contained (otherwise keeping them in sync becomes an issue)

[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?