search

Alexays / Waybar

Highly customizable Wayland bar for Sway and Wlroots based compositors. :v: :tada:
MIT License
6.32k stars 689 forks source link

GTK4 #2815

Open LukashonakV opened 8 months ago

LukashonakV commented 8 months ago

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

alebastr commented 8 months ago

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) :)

LukashonakV commented 8 months ago

Hi @alebastr , thank you for your response. This is definitely what I was needed , So. Regarding benefits... actually there are no any strong advantages waybar can get from the migration process... but according migration guide gtk team recommends to do migration from one major version to another... without any gaps. Of course it's not strictly.. but let's imagine tomorrow we will have GTK5 :))) In such case it would be more difficult to migrate Waybar from GTK3 to GTK5 ... + As I see GTK4 brought much more changes than for example GTK2->GTK3. ... So if it's possible such point can be counted as a one major benefit.. Second regarding eventbox . Actually as I saw according migration guide eventbox was dropped due to all items are are derived from the widget class . And Widget can handle any signals we need. But I still haven't had a chance to check it. If it's true I see we should revise a little AModule and ALabel architecture to satisfy new needs Third... regarding this https://gitlab.gnome.org/GNOME/gtk/-/issues/2132 - as I see this it the long long long story :))) I think in case if we wait this ticket is solved.... we will get GTK5 :))) Actually as I see GTK team strategy is : If possible to avoid responsibility for interaction with Wayland. And seems like that's why they cutoff some APIS. Please see comment -> https://gitlab.gnome.org/GNOME/gtk/-/issues/2132#note_760523 . So I don't see situation will change in a good way :)

Please make sure I don't insist on migration :) Just to try to figure out whether this good thing to start migration GTK3-GTK4... And please proceed with the sound criticism

@Alexays please your thoughts ? :)

Thanks

Alexays commented 8 months ago

Hi @alebastr and @LukashonakV. I agree with Aleksei, I don't think anyone is still building Waybar without gtk-layer-shell, so I'm pretty ok with dropping RawSurfaceImpl to have only gtk-layer-shell. But in view of a possible migration to GTK4, it would be a good idea to first drop RawSurfaceImpl and then check that on GTK4 the basic Widget class handles all the events, or whether we should try to migrate to GtkButton again. Btw, I'll create a branch with your work to let anyone start working on it, with no guarantee that it will be merged into master in the near future. To have a real advantage with this migration, it would have to bring new features that would be significant for users, why not listing these possibilities in this issue?

smsteward commented 8 months ago

@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.

5p4r74cu5 commented 7 months ago

To have a real advantage with this migration, it would have to bring new features that would be significant for users, why not listing these possibilities in this issue?

@Alexays

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.

lucyColeclough commented 6 months ago

@5p4r74cu5 The main changes in gtk4 were to the development experience imo, with event controllers, not having to show every widget, snapshot structure, nuking cell renderers. Things like this.

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. Arch gtkmm-3 seems to do the same though, :shrug:

5p4r74cu5 commented 6 months ago

@lucyColeclough

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.

lucyColeclough commented 6 months ago

@5p4r74cu5 Ah right forgot, its not as simple in 3

4194304 commented 6 months ago

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