Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gtk4. Migration. ALabel, AModule, factory, clock,cava. Events handling #2956

Open
wants to merge 602 commits into
base: gtk4
Choose a base branch
from

Conversation

LukashonakV
Copy link
Contributor

@LukashonakV LukashonakV commented Feb 22, 2024

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
ps_2024-02-24-20_33_49

@LukashonakV
Copy link
Contributor Author

LukashonakV commented Feb 26, 2024

Hi @Alexays , @alebastr
Finally AModule, ALabel handle events correct

2024-02-26.21-03-02.mp4

@LukashonakV LukashonakV changed the title Gtk4. Migration. ALabel, AModule, factory, clock Gtk4. Migration. ALabel, AModule, factory, clock. Events handling Feb 26, 2024
@LukashonakV LukashonakV changed the title Gtk4. Migration. ALabel, AModule, factory, clock. Events handling Gtk4. Migration. ALabel, AModule, factory, clock,cava. Events handling Feb 26, 2024
@LukashonakV
Copy link
Contributor Author

Partially covers #2815

@LukashonakV
Copy link
Contributor Author

LukashonakV commented Feb 27, 2024

+ backlight and harness

@LukashonakV
Copy link
Contributor Author

LukashonakV commented Apr 29, 2024

Hi @Alexays , @alebastr

Actually the main work is almost done

Leftovers are:

  1. ISSUES GTK4 #2815 - not covered modules
  2. Need to sync modules one by one with the master since c420b40
  3. Need to satisfy linter
  4. Need to rebuild docker containers
  5. 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

  1. UPower module is rewritten and should be rewritten in gtk3 too
  2. 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

2024-04-29.11-33-12.mp4

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

@LukashonakV
Copy link
Contributor Author

LukashonakV commented Apr 30, 2024

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

@LukashonakV
Copy link
Contributor Author

LukashonakV commented May 3, 2024

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

@LukashonakV
Copy link
Contributor Author

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

Alexays and others added 21 commits May 27, 2024 08:47
temperature: allow hwmon-path-abs as array
clang-tidy fixes in the privacy module
Fix Clock. Tooltip calendar text overflows(Alexays#2240)
Add GitHub action for nightly Docker image building
fix(Alexays#3211) change layer for mode invisible to nullopt
Checks the flake
Builds and tests the package
automatically updates the nix flake lock file

runs once a month
Was hardcoded to /tmp in previous versions
When the menu cannot be built (file not existing, or wrongly formatted),
     the menu is not created and a warning with an explanaition is
     displayed.
LukashonakV and others added 23 commits September 23, 2024 16:06
Signed-off-by: Viktar Lukashonak <[email protected]>
Fix: 3383. Clock. Default value for cldYearShift_ = 1900/01/01
The patches is the modification of downstream, it should not affect upstream. Any changes of upstream would caused patch fail.
As currently it is possible to turn the brightness to zero which may not
be desirable, this patch add a configurable brightness check.
nix: remove patches from downstream
Signed-off-by: Viktar Lukashonak <[email protected]>
Flake lock file updates:

• Updated input 'nixpkgs':
    'github:NixOS/nixpkgs/4f807e8940284ad7925ebd0a0993d2a1791acb2f?narHash=sha256-IiA3jfbR7K/B5%2B9byVi9BZGWTD4VSbWe8VLpp9B/iYk%3D' (2024-09-11)
  → 'github:NixOS/nixpkgs/06cf0e1da4208d3766d898b7fdab6513366d45b9?narHash=sha256-S5kVU7U82LfpEukbn/ihcyNt2%2BEvG7Z5unsKW9H/yFA%3D' (2024-09-29)
The waybar process does not exit instantaneously.
Signals may be recevied after main has started freeing resources.

When a worker thread is in `fgets` this time window can last forever.
An easy way to duplicate the crash is pressing ^C twice with a Hyprland module.

    Thread 1 "waybar" received signal SIGSEGV, Segmentation fault.
    spdlog::sinks::sink::should_log (this=0x5f620b542ca5,
        msg_level=spdlog::level::info)
        at /usr/src/debug/spdlog/spdlog-1.14.1/include/spdlog/sinks/sink-inl.h:13
    13	  return msg_level >= level_.load(std::memory_order_relaxed);
    (gdb) p $_siginfo._sifields._sigfault.si_addr
    $1 = (void *) 0x5f620b542cad
`Workspaces::*` and `IPC::startIPC` may both call `getSocketFolder` at the same time.

This randomly causes crashes and/or corruption of the socket path.

Typical crash A:

    [2024-10-16 07:42:09.987] [info] Hyprland IPC starting
    malloc(): unaligned tcache chunk detected
    [2024-10-16 07:42:09.987] [error] Hyprland IPC: Unable to connect?
    Thread 1 "waybar" received signal SIGABRT, Aborted.
    (gdb) bt
    #0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
    (omitted for brievety)
    Alexays#9  0x00007ffff64ae745 in operator new (sz=sz@entry=296) at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/new_op.cc:50
    Alexays#10 0x00007ffff65ab1f1 in std::filesystem::__cxx11::path::_List::_Impl::copy (this=0x555555a23350) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++17/fs_path.cc:249
    Alexays#11 0x00007ffff65ab3bd in std::filesystem::__cxx11::path::_List::_List (this=0x7fffffff9d30, other=<optimized out>) at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/unique_ptr.h:454
    Alexays#12 0x00005555556f4ab1 in waybar::modules::hyprland::IPC::getSocket1Reply(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
    Alexays#13 0x00005555556f5e3d in waybar::modules::hyprland::IPC::getSocket1JsonReply(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
    Alexays#14 0x000055555571289c in waybar::modules::hyprland::Workspaces::setCurrentMonitorId() ()

Typical crash B:

    [2024-10-16 10:01:15.859] [info] Hyprland IPC starting
    [2024-10-16 10:01:15.859] [info] Loading persistent workspaces from Hyprland workspace rules
    Thread 8 "waybar" received signal SIGSEGV, Segmentation fault.
    (gdb) bt
    #0  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy
        (__d=0x5555558fbca8 "/", __s=0x2973961a26d35726 <error: Cannot access memory at address 0x2973961a26d35726>, __n=1)
        at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:433
    (omitted for brievety)
    Alexays#15 waybar::modules::hyprland::IPC::getSocketFolder[abi:cxx11](char const*)
        (instanceSig=0x7fffffffe604 "4520b30d498daca8079365bdb909a8dea38e8d55_1729051218_1982280648") at ../src/modules/hyprland/backend.cpp:41
    Alexays#16 0x000055555564230f in waybar::modules::hyprland::IPC::startIPC()::{lambda()#1}::operator()() const ()
        at ../src/modules/hyprland/backend.cpp:70
    Alexays#17 0x00007ffff64e1c34 in std::execute_native_thread_routine (__p=0x5555558119c0) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
    Alexays#18 0x00007ffff62a339d in start_thread (arg=<optimized out>) at pthread_create.c:447
Fix a crash after handling SIGINT and a data race when initializing the Hyprland workspace modules
pulseaudio: volume indicator update on default output switch
Add warning threshold to temperature module
@LukashonakV LukashonakV force-pushed the gtk4 branch 2 times, most recently from 7086592 to 42d5ef3 Compare November 1, 2024 12:57
Signed-off-by: Viktar Lukashonak <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.