Implications of upstream dropping support for GTK3_MODULES

Hi, I've been happily using plotinus for a while now without issues. And I would like to keep using it. Seeing that upstream just dropped support for GTK3_MODULES I was wondering what this implies for the future of this excellent project.

Regards

[samdroid-apps]

I'm quite interested. That commit seems to be on "master". Is that where the Gtk 4 development is happening? Isn't Gtk3 supposed to be stable for now?

[p-e-w]

Thank you very much for pointing this out!

I have posted a question to gtk-devel-list here, which already has received a reply from a GTK+ core developer.

The bottom line, if I understood the reply correctly, is that Plotinus will continue to work in GTK+ 3.0, but not in GTK+ 4.0 unless introspection APIs are added to GTK+, which would probably mean a complete rewrite of Plotinus.

I'm not sure yet what the best course of action is so I'll think about it for a while. Any updates will be posted to this issue thread.

@p-e-w Happy to hear that plotinus will continue to work in GTK+ 3.0. I assume you're following GTK+ developments up-close(r) now this decision has been taken upstream. For the record I'll keep adding to this thread whenever I see something relevant if that's OK. Note that I get this via GNOME's GTK+ repo newsfeed.

Besides the aforementioned, there's been another commit recently, related to GTK_MODULES:
No need to clear GTK_MODULES anymore. Not a variable we care about nowadays.

I do hope those introspection API's are added, and that you find a way to keep Plotinus going. Regards.

[tallero]

@p-e-w Emmanuele Bassi agree that a command search palette would be a very welcomed feature in GTK+ 4.x
https://gitlab.gnome.org/GNOME/gtk/issues/1132
specific posts:
https://gitlab.gnome.org/GNOME/gtk/issues/1132#note_333322
https://gitlab.gnome.org/GNOME/gtk/issues/1132#note_333361

[lestcape]

I will shared what i considered that can be possible solutions. This are third ways:

1. Port all code to a libc module.
2. Continues using the current code with Gtk+2 and Gtk+3 and make a libc module only to Gtk+4
3. Try to find a vulnerability in some internal Gtk mechanism to then gain access to the gtk application scope. Probably this will be related with the Gtk extension point mechanism.

I think the point 1 is the right way to go for several reasons, like not over-complicate all with a lot of settings (point 2) and do not depend again of Gtk (point 3).

Anyway, I continues thinking if i really want rewrite the unity-gtk-module to hack Gtk from libc now as this will be something outside of the Gtk radar. The problem is that in my case, this will be to create a gnome shell extension to support the global menu in Gnome. So, does not convince me, because will be work to provide more thing to the gnome platform, when the gnome developers are the same people that don't make easy to me create software to his platform.

[tallero]

@lestcape actually there is no module needed because apparently they want the palette inside the toolkit.
https://gitlab.gnome.org/Teams/Design/os-mockups/blob/master/command-search/command-search.png

[lestcape]

@tallero The gnome developers don' t break the encapsulation. So, this will be for Gtk+4 and higher Gtk only. I don' t know if this can be unify with the rest of applications later, but if can be then, someone need to take care of update the support for Gtk+2 and Gtk+3. As the unity-gtk-module will be not useful for Gtk+4 i will not be that man that keep it working, because it will not be interesting to me as i will not provide a fully support with it to my use case (a global menu in gnome shell).

So, you already think this is done, because they planned add this to Gtk+4 for inside the application? In mi opinion it will be worse, because will not be fully for all Gtk versions and because the Gnome developers don' t recognize anything outside they own radars. So, not support for Qt, not support for electron, Firefox, libre office... 👎

[p-e-w]

Thank you for contributing to this discussion, @lestcape! Unfortunately, all of these options have severe downsides, not the least of them being that they would all essentially require a complete rewrite of Plotinus 😞

I currently have no plans to port Plotinus to GTK4 at all. I'm happy with the way it works on GTK3 and chasing APIs just because they exist is not my cup of tea.

That being said, Plotinus is certainly not going away – because GTK3 isn't. So far, the main "feature" of GTK4 seems to be that it constitutes yet another giant API break, like GTK3 did back in 2011. Third-party developers are already pretty tired of throwing away perfectly functioning code just to keep up with the latest trend in API design. With GIMP and Inkscape still using GTK2 and Firefox and LibreOffice only moving to GTK3 recently, I doubt any of them will be in a hurry to adopt GTK4 any time soon (not to mention that GTK4 hasn't even been released yet).

In summary, I fully expect GTK3 to remain the dominant GTK version for another 3-5 years at least. By the time this changes, it might well be that the above-mentioned designs have indeed made it into GTK core – at which point Plotinus will be no longer needed.

[lestcape]

@p-e-w I never test plotinus before and also right now I have not tried it. What I did right now was read your code. I was thinking that your code support Gtk2, Gtk3 and all others toolkit and things, using externals modules... I see that it's not in that way and what you have is your own Gtk3 module in vala.

So yes, for you this will be a big change with a big impact.

[cab404]

it stopped working for gimp:

(gimp:16260): Gtk-WARNING **: 01:28:03.832: GTK+ module /nix/store/r4sghipvq18spnrxhqlw1224pvnx6v3s-plotinus-0.2.0/lib/libplotinus.so cannot be loaded.
GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported.