Alexays
Gtk4. Migration. ALabel, AModule, factory, clock,cava. Events handling
Hi @Alexays , @alebastr
Finally I got first success execution with clock module. The only thing here is to add events controllers to the AModule class. Will check soon
Hi @Alexays , @alebastr Finally AModule, ALabel handle events correct
https://github.com/Alexays/Waybar/assets/23121044/b200a7c1-82f4-42ce-8950-2876830b718c
Hi @Alexays , @alebastr
Actually the main work is almost done
Leftovers are:
- ISSUES #2815 - not covered modules
- Need to sync modules one by one with the master since c420b406
- Need to satisfy linter
- Need to rebuild docker containers
- There is a bug with the Gtk::Label. When module sets the value to the set_tooltip_text/set_tooltip_markup Gtk::Label looks like try to refresh all tooltips for all opened Labels. And this leads to stealing of the focus. This point I'm trying to investigate now Can you please take this PR for now.
Thanks
During migration I found out
- UPower module is rewritten and should be rewritten in gtk3 too
- Client in GTK4 can be simplified due to no need to manage wayland logic more as Waybar relies on Gtk framework
Waybar under GTK4 example
https://github.com/Alexays/Waybar/assets/23121044/b5169b36-245c-4287-94c7-b4a60b1a0d63
UPD: Regarding 5-th point - I've created an issue to gtk4 https://gitlab.gnome.org/GNOME/gtk/-/issues/6674
UPD2: According https://discourse.gnome.org/t/gtk4-migration-label-and-tooltip-from-gtk3/20710/2, separate threads are not allowed to call GTK API themselves. For now, in GTK4, this leads to odd behaving for GTK Label
Hi @alebastr , @Alexays is it possible to have discussion somewhere regarding GTK4 and Waybar architecture ? The reason is I'm asking for : according documentation and the approach of GTK this framework since 3.36 release is no more thread safe ... and the approach is GTK API should be called from the main loop. Actually looking on the current Waybar architecture I'm inclined to think this architecture should be redesigned. Actually Waybar modules in their separate threads just need to do some logic and then signals main thread to start calling of the GTK API. So I need someones opinion on this point of view... or to have discussion with some agreed approach...
Hi @alebastr , @Alexays is it possible to have discussion somewhere regarding GTK4 and Waybar architecture ? The reason is I'm asking for : according documentation and the approach of GTK this framework since 3.36 release is no more thread safe ... and the approach is GTK API should be called from the main loop. Actually looking on the current Waybar architecture I'm inclined to think this architecture should be redesigned. Actually Waybar modules in their separate threads just need to do some logic and then signals main thread to start calling of the GTK API. So I need someones opinion on this point of view... or to have discussion with some agreed approach...
Need to wait for investigation of the core GTK team. To me it seems GTK issue which is under discussion here gtk4-migration-label-and-tooltip-from-gtk3
Hi @alebastr , @Alexays is it possible to have discussion somewhere regarding GTK4 and Waybar architecture ? The reason is I'm asking for : according documentation and the approach of GTK this framework since 3.36 release is no more thread safe ... and the approach is GTK API should be called from the main loop. Actually looking on the current Waybar architecture I'm inclined to think this architecture should be redesigned. Actually Waybar modules in their separate threads just need to do some logic and then signals main thread to start calling of the GTK API. So I need someones opinion on this point of view... or to have discussion with some agreed approach...
Need to wait for investigation of the core GTK team. To me it seems GTK issue which is under discussion here gtk4-migration-label-and-tooltip-from-gtk3
Finally no action from waybar side, https://gitlab.gnome.org/GNOME/gtk/-/commit/84fd420271928d171fd0d66a7f7d773fabb3ee2a GTK fixed an issue with flickering tooltips in GTK4