GTK4

[LukashonakV]

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

• Backlight
• Backlight/Slider
• Battery
• Bluetooth
• Cava
• CFFI
• Clock
• CPU
• Custom
• Disk
• DWL
• Gamemode
• Group
• Hyprland
• Idle Inhibitor
• Image
• JACK
• Keyboard State
• Language
• Memory
• MPD No guarantee
• MPRIS No guarantee
• Network
• Niri
• PulseAudio
• PulseAudio/Slider
• Privacy
• Sndio - need to check
• Systemd failed units
• River
• Sway
• WLR
• Temperature
• Tray - libdbusmenu is still in gtk3. Need to find another solution
• Taskbar
• UPower - fully rewritten
• WirePlumber No guarantee
• Workspaces
• User

---

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

---

Dependencies:

• gtk4: missbehavior of the Gtk::Label tooltip
• gtk3 migration gtk4 Label
• gtk4 Label
  Confirmed gtk4 - 4.17.0

[alebastr]

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]

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]

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]

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

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]

@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, 🤷

[5p4r74cu5]

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

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

[4194304]

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

[LukashonakV]

Hi @Alexays , finally .... GTK4 branch more or less working well on my machine,
Can you please force push gtk4 branch with the https://github.com/LukashonakV/Waybar/tree/gtk4 .
What is done:

• code base is using gtk4 framework
• all commits from the master branch till 5f26051 are merged into gtk4 . So for now gtk4 branch is synced with the master
• Linter is satisfied

What next:

1. Need to migrate docker files and update necessary dependencies to satisfy gtk4 branch
2. Need to migrate modules are left:
   • Hyprland
   • WLR
   • River
   • Tray - libdbusmenu is still in gtk3. Need to find another solution
   • Taskbar
   • Niri
3. Rotation of the Label is deprecated in GTK4. So for now this option is disabled. Possible solution is using Cairo for that purpose. It needs to be investigated

---

@Alexays can you publish this build as beta gtk4. ? Actually it's not an easy to merge such huge list of commits which where done since I started migration process.

Thank you

[LukashonakV]

Hi @Alexays , GTK4 base migration routine is done. All modules were migrated. All commits from the GTK3 master were picked up. Please give some feedback )

[System64fumo]

@LukashonakV Just happened to stumble here and noticed you guys were looking for a tray alternative?
I've written a "somewhat functional" tray for my gtk4 bar here
Feel free to use that as a reference, Hope that helps.

[LukashonakV]

Hi @Alexays , finally .... GTK4 branch more or less working well on my machine, Can you please force push gtk4 branch with the https://github.com/LukashonakV/Waybar/tree/gtk4 . What is done:

* [x]  code base is using gtk4 framework

* [x]  all commits from the master branch till [5f26051](https://github.com/Alexays/Waybar/commit/5f260516af9a3e5791c26c7fc18a85a47da5b23f) are merged into gtk4 . So for now gtk4 branch is synced with the master

* [x]  Linter is satisfied

What next:

1. Need to migrate docker files and update necessary dependencies to satisfy gtk4 branch

2. Need to migrate modules are left:
   
   * [x]  [Hyprland](https://github.com/Alexays/Waybar/wiki/Module:-Hyprland)
   * [x]  WLR
   * [x]  [River](https://github.com/Alexays/Waybar/wiki/Module:-River)
   * [ ]  [Tray](https://github.com/Alexays/Waybar/wiki/Module:-Tray) - libdbusmenu is still in gtk3. Need to find another solution
   * [x]  [Taskbar](https://github.com/Alexays/Waybar/wiki/Module:-Taskbar)
   * [x]  [Niri](https://github.com/Alexays/Waybar/wiki/Module:-Niri)

3. Rotation of the Label is deprecated in GTK4. So for now this option is disabled. Possible solution is using Cairo for that purpose. It needs to be investigated

@Alexays can you publish this build as beta gtk4. ? Actually it's not an easy to merge such huge list of commits which where done since I started migration process.

Thank you

Hi @Alexays , any feedback ?

[v4u6h4n]

grabs popcorn

[Beryesa]

Could it be merged with/skipping/except the libdbusmenu as experimental/beta until that part is figured out instead of holding it here?

[apiraino]

Could it be merged with/skipping/except the libdbusmenu as experimental/beta until that part is figured out instead of holding it here?

I - for one - find the Waybar tray a useful feature that I use, so I'd prefer not. Being the patch quite big (LukashonakV@654a326 ) I expect review and testing to take a bit of time.

[apiraino]

@LukashonakV first of all, thanks for working on this. Some initial feedback on the GTK4 patch.

I've built Waybar (8645115) applying your GTK4 patch, I took note that the updated dependencies are libgtkmm-4.0 and libgtk4-layer-shell (didn't identify more). When compiling the GTK4 branch I see some compile warnings, can't say if they were present in the GTK3 branch.

When running Waybar/GTK4 (waybar -l debug) I've found a few issues. Where can I report them, where do you want to track them?

• "bar configured" info message repeats continuously

[2024-11-16 12:16:17.449] [info] Bar configured (width: 1920, height: 33) for output: eDP-1
[2024-11-16 12:16:17.481] [info] Bar configured (width: 1920, height: 33) for output: HDMI-A-2
...

• bluetooth module does not work (unsure why, nothing is logged on stderr/stdout)
• Workspaces icons do not appear
• Tray icons do not appear (known issue)

Thoughts:

• Would it make sense opening a pull request on this repository to be sure your branch stays in sync with upstream and compiles cleanly?
• I wonder if the situation regarding gtk layer shell changed since this comment. Unsure about the context and implications here, but I could compile the Waybar+GTK4 patch by updating the libgtk4-layer-shell dependency.

[LukashonakV]

Hi @apiraino , thank you for your feedback.

So regarding some thoughts here

1. gtk4 should be at least 4.16 version. gtk4 Label
2. Actually Alex already created gtk4 branch 10+- months ago when I have the first attempt to build waybar with gtk4. But honestly saying it was very raw variant. A lot of changes are made since that time. + Actually I've recreated base gtk4 branch in order to have tree of commits synced with the master branch. That's the only reason I cannot create pull request for that. If Alex just override gtk4 branch forced by mine it's just align not only code base but tree of commits to. Then it'll be much easy to backport incoming commits from the master branch to the gtk4 and vice versa.
3. Regarding bluetooth module. Let me check once I have time
4. Regarding workspaces... which module do you use hyprland/sway ? There is difference between their implementation
5. gtk branch has got gtk-layer-shell dependency version 4. https://github.com/LukashonakV/Waybar/blob/654a3268983c05740d6f5dbde1f117a1b731ccc8/meson.build#L108 . If the question about dependency naming... it can be solved easily ... if it's necessary :)

[apiraino]

I've investigated a little bit the issues I mentioned before, here are some minimal configs to reproduce:

• "bar configured" info message repeats continuously:

{
    "modules-left": ["network"],
    "network": {
        "interval": 1
    }
}

• workspaces and bluetooth modules not showing up. you can probably trigger this If you uncomment fixed-center

{
    "height": 33,
    //"fixed-center": false,
    "modules-left": ["sway/workspaces", "sway/mode", "bluetooth"]
}

Hope it helps, thanks!

[LukashonakV]

Hi @apiraino
Actually the only thing I can reproduce is "bar configured" info message repeats continuously
All others stuff works for me well.
In the screenshot Top bar is running in GTK4. As you can see sway/workspaces in the left and bluetooth in the center works well for me. It might be the reason that you build waybar using patch from the mine branch and some things are not been took into the account.

---

Upd: can you try to build just mine gtk branch to check?

[apiraino]

@LukashonakV w.r.t. "workspaces and bluetooth modules not showing up". I can reproduce also with your branch (LukashonakV@654a326)

Just to be sure I made it clear how to reproduce, this config will reproduce the issue:

{
    "height": 33,
    "fixed-center": false,
    "modules-left": ["sway/workspaces", "sway/mode", "bluetooth"]
}

I also see a warning when starting Waybar:

(waybar:1542750): Gdk-WARNING **: 20:41:18.987: (../../../gdk/wayland/gdktoplevel-wayland.c:399):gdk_wayland_toplevel_compute_size: runtime check failed: (size.width > 0)

This other config does not reproduce the issue (and I don't see the warning either):

{
    "height": 33,
    // "fixed-center": false,
    "modules-left": ["sway/workspaces", "sway/mode", "bluetooth"]
}

[caffeine01]

Will this support things like CSS transforms? for example "-gtk-icon-transform" or just simply "transform".
For reference: https://docs.gtk.org/gtk4/css-properties.html

[tmccombs]

There is https://packages.debian.org/sid/libdbusmenu-gtk4

Although it might be debian specific.

It also might not be that bad to implement the menu manually instead of using a library.

I'd be willing to help with implementing that.

[Rayzeq]

Although the package you linked is called libdbusmenu-gtk4 for some reason, it's actually made for GTK-2+

[4194304]

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

Looking back at that is funny now since I use TWM, X11 cursors, hate GTK 4.0 (GTK theming), and am on my way to make my system completely monochrome (basically a classic X11 enthusiast)

[Beryesa]

...I use TWM, X11 cursors, hate GTK 4.0 (GTK theming), and am on my way to make my system completely monochrome...

This is only a GTK4 port, which has nothing to do with the theming. GTK4 is NOT just Libadwaita exclusively, they're indeed very separate things. You didn't even read up before having an opinion (hate) on it, let's not waste contributors' time here please.