GTK4 #2815
Comments
|
First of all, I'm not really sure that's a good idea right now. The
approach taken in gtk4-layer-shell, MITM shim library that patches Wayland
protocol messages to replace xdg-shell with layer-shell, seems a bit
fragile to me. Any request or extension protocol that references
non-existing xdg-shell objects may cause the compositor to drop the client.
I'd personally stay away from GTK4 until
https://gitlab.gnome.org/GNOME/gtk/-/issues/2132 is resolved.
Although gtk4-layer-shell works with the current release of gtk4, so maybe
I'm too skeptical. At least it's worth experimenting with.
GTK4 migration will make gtk4-layer-shell mandatory. You'll need to drop
RawSurfaceImpl (it's not possible to make it work), and remove the meson
feature, the configuration flag and all the ifdefs.
This could be started in the current GTK3 version, as I don't see much
sense in keeping an inferior RawSurfaceImpl anymore. gtk-layer-shell is
widespread and I don't believe anyone's still building Waybar without
it. @Alexays,
WDYT?
Please, also check the attempt to replace GtkEventBox with GtkButton and
the resulting fallout. That would be another prerequisite for migration, as
GTK4 removed EventBox
<https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-gtkeventbox>, so
it might be worth recovering the code and addressing the remaining blocking
issues.
As a side-note, what are the benefits of GTK4 port? GTK3 will be maintained
for a while, since even GNOME haven't finished migrating all the
components. And by the time GTK3 is EOL, we'll have to start considering
freshly released GTK5 (which is not even being developed right now) :)
|
|
Hi @alebastr , thank you for your response. This is definitely what I was needed , Please make sure I don't insist on migration :) Just to try to figure out whether this good thing to start migration GTK3-GTK4... @Alexays please your thoughts ? :) Thanks |
|
Hi @alebastr and @LukashonakV. |
|
@LukashonakV I had started doing this same thing a few weeks ago as a side project, albeit in Python (I don't know any C++ unfortunately due to some bad experiences with it in undergrad). I have some basic functions written and some template classes for the bar itself, but I'm having a hard time getting the widget templates off the ground (I'm a full time SQL dev, so my free time is quite limited). If you know any Python and would like a collaborator, I'd be down to help realize this. |
Hey :-) I apologise in advance if I am misunderstanding, as my technical knowledge is limited to bash scripting, but I've read in other issues that GTK4 may be relevant to implementing some aesthetically oriented features, like hover states. I know that at the end of the day aesthetics will always be trumped by other more practical concerns, however basic features like hover states probably have a significant impact on peoples interest in using waybar. I know this is subjective, but it certainly gives the bar a somewhat dated feel. |
|
@5p4r74cu5 The aesthetic differences were ported to gtk3 and waybar uses heavy css. The main reason someone might want to keep up is the same with most projects in that the current version is the one that people are putting effort in to keep it compliant with all surrounding software. That said, people seem good at making old software still function, such as gimp which is still on gtk2. On that note, when bumping the package in guix from 0.9.20 -> 0.9.21 the gtkmm-3 package uses glibmm-2.64 which is incompatible with c++ 20, giving up for now. |
|
Interesting, guess that explains why gimp is so damn ugly. Perhaps GTK4 has more of an indirect role in effecting the aesthetics, like regarding hover states, as its mentioned as one of the things holding up #1120. I know hover states are just one feature, but I think it has a disproportional impact on the user experience. States visually changing on hover is so typical in modern GUIs that it essentially feels like Waybar is broken, on an intuitive level. That said, I hear you that from a developer perspective the changes in the development experience will overshadow the effects for the average user, like me :-) EDIT: Grammar corrections. |
|
@5p4r74cu5 |
|
I fully support this. Being able to not use things like blur effects for me isn't acceptable. For now I'll be using workarounds to that specific problem |
Hi @Alexays , @alebastr I've done some digging into GTK4 and opportunity to migrate Waybar to it.
So. I have the first base example of the Waybar which can be build and run with gtkmm4 .
There only base engine... without any modules and event handlers. But I think it's a good start to migrate Waybar.
@Alexays is it possible for you to create for example separate branch and mark it with labels: unstable, gtk4 and to do cloning from my branch : https://github.com/LukashonakV/Waybar/tree/gtk4
I think it will provide an opportunity to contributors to make contributions, fix errors, find more effective approaches, bring new ideas, speedup the process
About versioning: 4.1.0 - the first digit means (stable release version. Currently it points to GTK4 chain), the second digit experimental version. The third digit update of the stable release. So for example the first stable release of the Waybar GTK4 should be looked like: 4.0.1. - The same versioning system now for example is used by Wine project.
So current 4.1.0 - meanse - Waybar 4 experimental 1 release without updates of the stable release
Once this approach is approved and separate branch is created it's possible to keep TODO list in this issue.
Thank you
Migration tasks
Once Waybar is migrated need to do additional sync with the master in order to pick up all PR are done since migration process was going on
The text was updated successfully, but these errors were encountered: