lxqt-panel icon indicating copy to clipboard operation
lxqt-panel copied to clipboard

Wlroots taskbar

Open marcusbritanicus opened this issue 1 year ago • 89 comments

This PR adds a generic wlroots backend support for the the taskbar and desktop-switcher plugins.

@gfgit: I took lxqt-panel:git, then merged #2041 and #2043. I hope this is what I was supposed to do. If something's amiss, please do let me know.

One of the issues we face is the wlroots backend does not support virtual desktops. However, various compositors (wayfire, sway, hyprland, etc) have their own mechanisms to provide this feature.

  1. swaymsg provides a very fine-grained control to handle windows and virtual-desktops on sway.
  2. Wayfire:git has a rudimentary IPC support (not as developed as swaymsg) with which we can develop something similar to swaymsg. Alternatively, I am developing three protocols that provide virtual-desktop and toplevel management support via protocols.
  3. Hyprthing is for Hyprland what swaymsg is for sway? I do not know much about this.

So it would be beneficial if we provide per-compositor support. As discussed in #2531, the best way forward is to develop a plugin interface for the wayland backend. Currently, I have the following structure in mind:

panel/backends/
  - wayland/
    - plasma/
      * lxqtbackendplasma.cpp
      * lxqtbackendplasma.h
    - wlroots/
      * lxqtbackendwlroots.cpp
      * lxqtbackendwlroots.h
    - wayfire/
      * lxqtbackendwayfire.cpp
      * lxqtbackendwayfire.h
    - sway/
      * lxqtbackendsway.cpp
      * lxqtbackendsway.h
    - hyprland/
      * lxqtbackendhyprland.cpp
      * lxqtbackendhyprland.h
    - lxqtwaylandbackend.cpp
    - lxqtwaylandbackend.h
  - xcb/
    - lxqttaskbarbackend_x11.cpp
    - lxqttaskbarbackend_x11.h
  - ilxqttaskbarabstractbackend.cpp
  - ilxqttaskbarabstractbackend.h
  - lxqttaskbardummybackend.cpp
  - lxqttaskbardummybackend.h

Few points:

  1. lxqtwaylandbackend.cpp should attempt to detect the DE and load the suitable plugin. The DE detection can be based on a user settings or XDG_CURRENT_DESKTOP.
  2. If we're using a protocol (say, like wlr-foreign-toplevel, or wayfire-desktop-shell), we should also attempt to verify that the compositor is advertising the said protocol.
  3. If the compositor-specific protocol/support is unavailable (for example, when using wayfire, if ipc plugin is not loaded or similar), we should fallback to wlroots.
  4. If wlroots (i.e. wlr-foreign-toplevel) is not available (for example, foregin-toplevel plugin is not loaded in wayfire), the default dummy wayland backend (as provided by lxqtwaylandbackend.cpp will be used).

Changes made:

  1. I have moved all the files from panel/backends/wayland/ to panel/backends/wayland/plasma
  2. panel/backends/wayland/wlroots implements the wlroots backend.
  3. Line 50/51 panel/lxqtpanelapplication.cpp to use only wlroots backend. (This needs to be fixed)

Current state:

  1. On a wlroots-based compositor, following works:
    • Listing all the currently open windows.
    • Click to focus
    • Add newly opened windows
    • Remove closed windows
    • desktop-switcher plugin (It will simply show only one virtual desktop named ("Desktop 1" with id "desktop-1")
  2. On a wlroots-based compositor, following does not work:
    • Grouping does not work properly
    • Window icons
  3. On a wlroots-based compositor, what will not work:
    • Move to output, move to desktop, shade, pin on top/bottom (No support from the protocol)
    • Anything related to virtual desktops (at least until ext-workspace-* support gets added)
  4. In it's current state, taskbar and desktop-switcher plugins will crash the panel when run on any non-wlroots compositor (for example, plasma).

Note: For the purpose of our discussion here, by "non-wlroots compositor", what I mean is a compositor that does not implement wlr-foreign-toplevel protocol.

cc: @stefonarch @tsujan

marcusbritanicus avatar Mar 27 '24 05:03 marcusbritanicus

@gfgit When I first compiled and installed lxqt-panel, I faced one major error:

AutoMoc subprocess error
------------------------
The moc process failed to compile
  "SRC:/plugin-taskbar/lxqttaskbarplugin.h"
into
  "SRC:/.build/plugin-taskbar/taskbar_autogen/EWIEGA46WW/moc_lxqttaskbarplugin.cpp"
Process failed with return value 1

Command
-------
/usr/lib/qt6/moc "-DLXQT_DATA_DIR=\"/usr/share\"" "-DLXQT_ETC_XDG_DIR=\"/etc/xdg\"" "-DLXQT_GRAPHICS_DIR=\"/usr/share/lxqt/graphics\"" "-DLXQT_MAJOR_VERSION=\"2\"" "-DLXQT_MINOR_VERSION=\"0\"" "-DLXQT_PANEL_VERSION=\"2.0.0\"" "-DLXQT_PATCH_VERSION=\"0\"" "-DLXQT_RELATIVE_SHARE_DIR=\"lxqt\"" "-DLXQT_RELATIVE_SHARE_TRANSLATIONS_DIR=\"lxqt/translations\"" "-DLXQT_SHARE_DIR=\"/usr/share/lxqt\"" "-DLXQT_SHARE_TRANSLATIONS_DIR=\"/usr/share/lxqt/translations\"" "-DLXQT_VERSION=\"2.0.0\"" "-DPLUGIN_DIR=\"/usr/lib/lxqt-panel\"" -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_FROM_BYTEARRAY -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_NO_URL_CAST_FROM_STRING -DQT_SVG_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DWITH_DESKTOPSWITCH_PLUGIN -DWITH_FANCYMENU_PLUGIN -DWITH_MAINMENU_PLUGIN -DWITH_QUICKLAUNCH_PLUGIN -DWITH_SHOWDESKTOP_PLUGIN -DWITH_TASKBAR_PLUGIN -I/home/cosmos/Softwares/Projects/LXQt/lxqt-panel/.build/plugin-taskbar -I/home/cosmos/Softwares/Projects/LXQt/lxqt-panel/plugin-taskbar -I/usr/include/qt6/QtWidgets -I/usr/include/qt6 -I/usr/include/qt6/QtCore -I/usr/lib/qt6/mkspecs/linux-g++ -I/usr/include/qt6/QtGui -I/usr/include/lxqt -I/usr/include/lxqt/LXQt -I/usr/include/KF6/KWindowSystem -I/usr/include/qt6/QtDBus -I/usr/include/qt6xdg -I/usr/include/qt6/QtXml -I/usr/include/qt6xdgiconloader -I/usr/include/qt6xdgiconloader/4.0.0 -I/usr/include/qt6/QtSvg -I/usr/include/lxqt-globalkeys -I/usr/include -I/opt/aocc/include -I/usr/include/c++/13.2.1 -I/usr/include/c++/13.2.1/x86_64-pc-linux-gnu -I/usr/include/c++/13.2.1/backward -I/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include -I/usr/local/include -I/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include-fixed --include /home/cosmos/Softwares/Projects/LXQt/lxqt-panel/.build/plugin-taskbar/taskbar_autogen/moc_predefs.h --output-dep-file -o /home/cosmos/Softwares/Projects/LXQt/lxqt-panel/.build/plugin-taskbar/taskbar_autogen/EWIEGA46WW/moc_lxqttaskbarplugin.cpp /home/cosmos/Softwares/Projects/LXQt/lxqt-panel/plugin-taskbar/lxqttaskbarplugin.h

Output
------
/home/cosmos/Softwares/Projects/LXQt/lxqt-panel/plugin-taskbar/lxqttaskbarplugin.h:62:1: error: Undefined interface

Note that this was the first time I installed lxqt, which means that /usr/include/lxqt/ilxqtpanelplugin.h did not exist. Once I manually copied ilxqtpanel.h, ilxqtpanelplugin.h, lxqtpanelglobals.h and pluginsettings.h to /usr/include/lxqt this error vanished. It looks to me that moc is unable to locate ilxqtpanelplugin.h in the source tree.

Secondly, another problem which I faced was:

/usr/bin/ld: backends/xcb/liblxqt-panel-backend-xcb.a(lxqttaskbarbackend_x11.cpp.o): in function `LXQtTaskbarX11Backend::moveApplication(unsigned long long)':
lxqttaskbarbackend_x11.cpp:(.text+0x209d): undefined reference to `NETRootInfo::moveResizeRequest(unsigned int, int, int, NET::Direction, unsigned char, NET::RequestSource)'
/usr/bin/ld: backends/xcb/liblxqt-panel-backend-xcb.a(lxqttaskbarbackend_x11.cpp.o): in function `LXQtTaskbarX11Backend::resizeApplication(unsigned long long)':
lxqttaskbarbackend_x11.cpp:(.text+0x21ef): undefined reference to `NETRootInfo::moveResizeRequest(unsigned int, int, int, NET::Direction, unsigned char, NET::RequestSource)'
collect2: error: ld returned 1 exit status

I ran sudo ldconfig as per @stefonarch's suggestion, but that did not work. So, currently, I have commented out the offending two lines in my copy. I have two versions of KWindowSystem: 6.0.0 and 5.115.0. Both versions have this function. So I am at a loss to understand why this error pops up.

Thirdly and lastly, I was testing lxqt-panel (wlroots-taskbar edition) on embedded kwin_wayland: XDG_CURRENT_DESKTOP="LXQt:Plasma:KDE:kwin_wayland" kwin_wayland -- lxqt-panel --config ~/.config/lxqt/panel.conf I noticed a peculiarity. Your code depends on org_kde_plasma_window_management interface. But to my great surprise, I noticed that this particular interface is not advertised by kwin_wayland!! This might be the reason why the taskbar plugin does not work on kwin_wayland even though it's loaded.

marcusbritanicus avatar Mar 27 '24 18:03 marcusbritanicus

Issues I see

  • Taskbar settings:
    • "Show only minimized" apps shows none.
    • All workspace related settings but that's to expect

Multiple click behavior issues:

  • Wayfire: none found
  • Labwc:
    • if only one window on a workspace is open this can be toggled always with left click on taskbar button.
    • if more than one are on the same workspace when switching between them and minimizing/restoring one it can happen that the active one is not highlighted anymore but has focus, on the first click it actives the button but the window is already active (end of video)

https://github.com/lxqt/lxqt-panel/assets/10681413/a1235abe-f927-4f0b-820a-1e89e299073a

  • sway: In future on sway minimize/restore could be greyed out, there is no issue but at the moment the cursors hovers the bar all buttons get inactive state, not bad but strange:

https://github.com/lxqt/lxqt-panel/assets/10681413/20d1eefb-76c0-4e1e-9fb2-b379c2921b60

  • Hyprland ok, minimize doesn't exist too here.

stefonarch avatar Mar 28 '24 07:03 stefonarch

sway: In future on sway minimize/restore could be greyed out, there is no issue but at the moment

Alternatively, we can send minimized views to scratchpad.

the cursors hovers the bar all buttons get inactive state, not bad but strange

I too noticed this. But not much can be done about it. On sway, the view with cursor has focus, and is activated as well. So when you move the cursor to the panel, it gains focus (because you've asked for it in layer-shell), and gets activated, meaning, the rest of the views lose their activation status.

Edit: Upon reflection, this looks like a lxqt-panel bug. It does not need keyboard focus except in certain cases. But I think it requests keyboard-interaction on demand.

marcusbritanicus avatar Mar 28 '24 08:03 marcusbritanicus

Thirdly and lastly, I was testing lxqt-panel (wlroots-taskbar edition) on embedded kwin_wayland: XDG_CURRENT_DESKTOP="LXQt:Plasma:KDE:kwin_wayland" kwin_wayland -- lxqt-panel --config ~/.config/lxqt/panel.conf I noticed a peculiarity. Your code depends on org_kde_plasma_window_management interface. But to my great surprise, I noticed that this particular interface is not advertised by kwin_wayland!! This might be the reason why the taskbar plugin does not work on kwin_wayland even though it's loaded.

org_kde_plasma_window_management is a restricted interface granted only to privileged clients. To be one:

  1. .desktop file must have absolute path in its Exec= field. I've just pushed a commit to auto generate this path based on CMake variables.
  2. .desktop file must contain X-KDE-Wayland-Interfaces=org_kde_plasma_window_management
  3. .desktop file must be in canonical locations, meaning the /etc/xdg/autostart does not count
  4. .desktop file's OnlyShowIn= must be compatible with current XDG_CURRENT_DESKTOP. Maybe we can add an Hidden=true to then hide it from applications menu.

gfgit avatar Mar 28 '24 10:03 gfgit

Note that this was the first time I installed lxqt, which means that /usr/include/lxqt/ilxqtpanelplugin.h did not exist. Once I manually copied ilxqtpanel.h, ilxqtpanelplugin.h, lxqtpanelglobals.h and pluginsettings.h to /usr/include/lxqt this error vanished. It looks to me that moc is unable to locate ilxqtpanelplugin.h in the source tree.

I had this issue but I don't remember how I solved it rigth now. Will check

gfgit avatar Mar 28 '24 10:03 gfgit

Maybe we can add an Hidden=true to then hide it from applications menu.

It's already hidden because it is a LXQt-module which are hidden by default afaik.

stefonarch avatar Mar 28 '24 13:03 stefonarch

I didn't notice it until now but the panel dumps core, sometimes several times, on session start on wlroots-based compositors when taskbar-plugin is present and some applications are in autostart. https://github.com/lxqt/lxqt/discussions/2547#discussioncomment-8974141

Core was generated by `/usr/bin/lxqt-panel'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000654c32139343 in ?? ()
[Current thread is 1 (Thread 0x7f3cb2f65940 (LWP 1795))]
(gdb)
(gdb) where
#0  0x0000654c32139343 in ??? ()
#1  0x00007f3cb4790ca9 in ??? () at /usr/lib/libQt6Core.so.6
#2  0x0000654c3213fb44 in ??? ()
#3  0x00007f3cb4790ca9 in ??? () at /usr/lib/libQt6Core.so.6
#4  0x0000654c3213d6c8 in ??? ()
#5  0x00007f3cb5ce3596 in ??? () at /usr/lib/libffi.so.8
#6  0x00007f3cb5ce000e in ??? () at /usr/lib/libffi.so.8
#7  0x00007f3cb5ce2bd3 in ffi_call () at /usr/lib/libffi.so.8
#8  0x00007f3cb60f2645 in ??? ()
    at /usr/lib/libwayland-client.so.0
#9  0x00007f3cb60f2e73 in ??? ()
    at /usr/lib/libwayland-client.so.0
#10 0x00007f3cb60f313c in wl_display_dispatch_queue_pending ()
    at /usr/lib/libwayland-client.so.0
#11 0x00007f3cb616198e in ??? ()
    at /usr/lib/libQt6WaylandClient.so.6
#12 0x00007f3cb477c2c7 in QObject::event(QEvent*) ()
    at /usr/lib/libQt6Core.so.6
#13 0x00007f3cb56f438b in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt6Widgets.so.6
#14 0x00007f3cb4739818 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt6Core.so.6
#15 0x00007f3cb4739b9b in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/libQt6Core.so.6
#16 0x00007f3cb49758a4 in ??? () at /usr/lib/libQt6Core.so.6
#17 0x00007f3cb4021199 in ??? () at /usr/lib/libglib-2.0.so.0
#18 0x00007f3cb40803bf in ??? () at /usr/lib/libglib-2.0.so.0
#19 0x00007f3cb4020712 in g_main_context_iteration ()
    at /usr/lib/libglib-2.0.so.0
#20 0x00007f3cb49739c4 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt6Core.so.6
#21 0x00007f3cb4743d6e in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt6Core.so.6
#22 0x00007f3cb473c2b8 in QCoreApplication::exec() ()
    at /usr/lib/libQt6Core.so.6
#23 0x0000654c3204922a in ??? ()
#24 0x00007f3cb5443cd0 in ??? () at /usr/lib/libc.so.6
#25 0x00007f3cb5443d8a in __libc_start_main ()
    at /usr/lib/libc.so.6
#26 0x0000654c32049ab5 in _start ()

stefonarch avatar Apr 02 '24 21:04 stefonarch

Maybe we can add an Hidden=true to then hide it from applications menu.

It's already hidden because it is a LXQt-module which are hidden by default afaik.

On OpenBox running LXQt Panel, I can see it in FancyMenu (first item, unnamed). By selecting "Add to desktop" you can verify it's actually lxqt-panel.desktop originated from lxqt_panel-wayland.desktop.in file.

EDIT: NoDisplay=true seems better than Hidden=true

gfgit avatar Apr 03 '24 21:04 gfgit

On OpenBox running LXQt Panel, I can see it in FancyMenu (first item, unnamed). By selecting "Add to desktop" you can verify it's actually lxqt-panel.desktop originated from lxqt_panel-wayland.desktop.in file.

EDIT: NoDisplay=true seems better than Hidden=true

Maybe because openbox is no DE? Anyway I'm fine with all.

stefonarch avatar Apr 04 '24 11:04 stefonarch

@gfgit When I first compiled and installed lxqt-panel, I faced one major error:

AutoMoc subprocess error
------------------------
The moc process failed to compile
  "SRC:/plugin-taskbar/lxqttaskbarplugin.h"
into
  "SRC:/.build/plugin-taskbar/taskbar_autogen/EWIEGA46WW/moc_lxqttaskbarplugin.cpp"
Process failed with return value 1

Command
-------
/usr/lib/qt6/moc "-DLXQT_DATA_DIR=\"/usr/share\"" "-DLXQT_ETC_XDG_DIR=\"/etc/xdg\"" "-DLXQT_GRAPHICS_DIR=\"/usr/share/lxqt/graphics\"" "-DLXQT_MAJOR_VERSION=\"2\"" "-DLXQT_MINOR_VERSION=\"0\"" "-DLXQT_PANEL_VERSION=\"2.0.0\"" "-DLXQT_PATCH_VERSION=\"0\"" "-DLXQT_RELATIVE_SHARE_DIR=\"lxqt\"" "-DLXQT_RELATIVE_SHARE_TRANSLATIONS_DIR=\"lxqt/translations\"" "-DLXQT_SHARE_DIR=\"/usr/share/lxqt\"" "-DLXQT_SHARE_TRANSLATIONS_DIR=\"/usr/share/lxqt/translations\"" "-DLXQT_VERSION=\"2.0.0\"" "-DPLUGIN_DIR=\"/usr/lib/lxqt-panel\"" -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_FROM_BYTEARRAY -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_NO_URL_CAST_FROM_STRING -DQT_SVG_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DWITH_DESKTOPSWITCH_PLUGIN -DWITH_FANCYMENU_PLUGIN -DWITH_MAINMENU_PLUGIN -DWITH_QUICKLAUNCH_PLUGIN -DWITH_SHOWDESKTOP_PLUGIN -DWITH_TASKBAR_PLUGIN -I/home/cosmos/Softwares/Projects/LXQt/lxqt-panel/.build/plugin-taskbar -I/home/cosmos/Softwares/Projects/LXQt/lxqt-panel/plugin-taskbar -I/usr/include/qt6/QtWidgets -I/usr/include/qt6 -I/usr/include/qt6/QtCore -I/usr/lib/qt6/mkspecs/linux-g++ -I/usr/include/qt6/QtGui -I/usr/include/lxqt -I/usr/include/lxqt/LXQt -I/usr/include/KF6/KWindowSystem -I/usr/include/qt6/QtDBus -I/usr/include/qt6xdg -I/usr/include/qt6/QtXml -I/usr/include/qt6xdgiconloader -I/usr/include/qt6xdgiconloader/4.0.0 -I/usr/include/qt6/QtSvg -I/usr/include/lxqt-globalkeys -I/usr/include -I/opt/aocc/include -I/usr/include/c++/13.2.1 -I/usr/include/c++/13.2.1/x86_64-pc-linux-gnu -I/usr/include/c++/13.2.1/backward -I/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include -I/usr/local/include -I/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include-fixed --include /home/cosmos/Softwares/Projects/LXQt/lxqt-panel/.build/plugin-taskbar/taskbar_autogen/moc_predefs.h --output-dep-file -o /home/cosmos/Softwares/Projects/LXQt/lxqt-panel/.build/plugin-taskbar/taskbar_autogen/EWIEGA46WW/moc_lxqttaskbarplugin.cpp /home/cosmos/Softwares/Projects/LXQt/lxqt-panel/plugin-taskbar/lxqttaskbarplugin.h

Output
------
/home/cosmos/Softwares/Projects/LXQt/lxqt-panel/plugin-taskbar/lxqttaskbarplugin.h:62:1: error: Undefined interface

Note that this was the first time I installed lxqt, which means that /usr/include/lxqt/ilxqtpanelplugin.h did not exist. Once I manually copied ilxqtpanel.h, ilxqtpanelplugin.h, lxqtpanelglobals.h and pluginsettings.h to /usr/include/lxqt this error vanished. It looks to me that moc is unable to locate ilxqtpanelplugin.h in the source tree.

Compiling on a clean VM with Manjaro I run exactly into this. EDIT: looks like https://github.com/lxqt/lxqt-panel/pull/2041 doesn't have that problem, also not the ld issue and compiling ti first this PR compiles fine. Looks like something got lost in between.

stefonarch avatar Apr 04 '24 18:04 stefonarch

@marcusbritanicus Hi, didn't have time to properly test yet sorry. But... Could we improve the generic wayland backend proxy thing? I mean it's ju duplicated code with no added logic. I have 2 ideas:

  1. Move wayland backend creation to lxqtpanelapplication. So where we create the X11 backend we also directly create Plasma/Wlroots/other. This would introduce wayland specific code in generic code (compositor detection logic) so maybe we can make a factory function which hides this logic and put it in the toplevel wayland folder.

  2. Another option would be using only one wayland backend. The plasma and wlroots backend are quite similar so we could share more code between them. This option is a bit more difficult to implement.

gfgit avatar Apr 05 '24 09:04 gfgit

Hi, didn't have time to properly test yet sorry.

That's totally fine.

But... Could we improve the generic wayland backend proxy thing? I mean it's ju duplicated code with no added logic.

I was waiting for your input regarding this. Since it's not time-bound (i.e., we're likely to make a release without this PR), I think we can take this slow.

Absolutely: I just took the dummy-backend, and added wayland bits. All I wanted to do was enable a means for @stefonarch (and the rest of us as well) to test the code. Secondly, we (@stefonarch, and I) and come to a consensus that a plugin based approach would be better. Wayland (wlroots included) is a lot of things, but sadly, feature-rich is not one of them. And different compositors have taken their own approach to achieve their end goals. So the unfortunate truth is that we will have to invest in compositor-specific codes. And this means having a plugin-based architecture is a must.

I have 2 ideas:

  1. Move wayland backend creation to lxqtpanelapplication. So where we create the X11 backend we also directly create Plasma/Wlroots/other. This would introduce wayland specific code in generic code (compositor detection logic) so maybe we can make a factory function which hides this logic and put it in the toplevel wayland folder.
  2. Another option would be using only one wayland backend. The plasma and wlroots backend are quite similar so we could share more code between them. This option is a bit more difficult to implement.

I think we should go for the first approach. On the surface, it does look like plasma and wlroots appear the same, but I think I have rewritten both the LXQtTaskbarWlrootsBackend and LXQtTaskbarWlrootsWindowManagment classes after copying your plasma code. So putting in effort to separate out common code between them would not be worth it.

Secondly, it will be difficult to add the compositor-specific code (in approach 2). Currently, as far as I am aware, we have special code for 1) plasma, and further we can develop (sufficiently easily) compositor specific code for 2) wayfire, 3) sway, 4) hyprland. If we annoy consolatis and johanmalm sufficiently, may be labwc as well. And these are quite popular ones. It will take a at least a few years to achieve basic feature parity among these to get rid of these special codes.

marcusbritanicus avatar Apr 05 '24 10:04 marcusbritanicus

I like plugin based approach. So we can make a generic function createWaylandBackend() which internally detects compositor and chooses the best wayland plugin and returns a pointer to a new backend instance. This way generic code does not need to know about wayland specific things. We could also make each wayland plugin probe itself so in case we want to dynamically load them from shared libraries (like a real plugin) we don't need to hardcode which compositors are currently supported.

gfgit avatar Apr 05 '24 11:04 gfgit

As for testing I can switch fine between all mentioned compositors without issues using this PR - great work from you both!

Maybe it's early to talk about but I think we should have a WIP_wayland branch for this at the end, so we could have it on AUR (or compiling) for getting advanced user's feedback. Our git checkouts were always meant to be stable, having a separate branch would give us more freedom in some sense.

stefonarch avatar Apr 05 '24 12:04 stefonarch

So we can make a generic function createWaylandBackend() which internally detects compositor and chooses the best wayland plugin and returns a pointer to a new backend instance.

This would be perfect.

This way generic code does not need to know about wayland specific things. We could also make each wayland plugin probe itself so in case we want to dynamically load them from shared libraries (like a real plugin) we don't need to hardcode which compositors are currently supported.

Absolutely. We can develop some ranking system (automated + user-controllable) using which we can pick the platform plugin. For example, for wayfire, we can (or people who are interested) easily develop two plugins - one based on protocols, the other based on ipc. In such cases, if we wish, we can allow the user to choose the backend.

marcusbritanicus avatar Apr 05 '24 12:04 marcusbritanicus

NoDisplay=true seems better than Hidden=true

Yes, this works fine, noticed only now that it appears without title on top under "All Applications" otherwise.

stefonarch avatar Apr 08 '24 19:04 stefonarch

NoDisplay=true seems better than Hidden=true

Yes, this works fine, noticed only now that it appears without title on top under "All Applications" otherwise.

Done in #2043 @marcusbritanicus Can I force-push it to cleanup recent history and you rebase your branches on top? But we could also do this later when we are ready to merge.

EDIT: my intention is that once layer shell code is merged into master, I'll rebase may WM abstraction and Plasma backend PRs on top of new master because currently they still have old commits about layer shell which would then become duplicates of #2048

gfgit avatar Apr 09 '24 09:04 gfgit

@gfgit feel free to force push. I don't mind. If it's too messy, I don't mind opening a new PR.

marcusbritanicus avatar Apr 09 '24 15:04 marcusbritanicus

@gfgit feel free to force push. I don't mind. If it's too messy, I don't mind opening a new PR.

Your PR is fine. I just like rebasing, don't know why XD. When #2048 is merged I'll try move my branches on top of master and you can then move your PR on top

gfgit avatar Apr 09 '24 15:04 gfgit

@marcusbritanicus I've cleaned up and rebased my two PR I've also made a copy of your wlroots branch and rebased it on top of new #2043 so you don't have to waste time rebasing yourself. I've uploaded it to gfgit/wlroots-taskbar_new You could reset your branch to that.

gfgit avatar Apr 11 '24 14:04 gfgit

@gfgit thanks a lot. I'm most likely to be busy until 18th. If I find some time in between, I'll update my PR, otherwise I'll get back to it after 18th.

marcusbritanicus avatar Apr 12 '24 02:04 marcusbritanicus

I've no idea why and where but when I use this branch the panel crashes continuously now (on login, while configuring), independent from taskbar being present or not.

stefonarch avatar Apr 16 '24 17:04 stefonarch

@gfgit I just updated my repo.. I hope I have done it right...

@stefonarch Maybe, now it will not crash?? Let's debug it when possible.

marcusbritanicus avatar Apr 18 '24 03:04 marcusbritanicus

@stefonarch Maybe, now it will not crash?? Let's debug it when possible.

Unfortunately it does still crash when adding a third panel already (without taskbar present).

(gdb) where
#0  0x00005cef615bd033 in ??? ()
#1  0x0000743d09797609 in ??? () at /usr/lib/libQt6Core.so.6
#2  0x00005cef615c3834 in ??? ()
#3  0x0000743d09797609 in ??? () at /usr/lib/libQt6Core.so.6
#4  0x00005cef615c13b8 in ??? ()
#5  0x0000743d0a476596 in ??? () at /usr/lib/libffi.so.8
#6  0x0000743d0a47300e in ??? () at /usr/lib/libffi.so.8
#7  0x0000743d0a475bd3 in ffi_call () at /usr/lib/libffi.so.8
#8  0x0000743d0afb1645 in ??? ()
    at /usr/lib/libwayland-client.so.0
#9  0x0000743d0afb1e73 in ??? ()
    at /usr/lib/libwayland-client.so.0
#10 0x0000743d0afb213c in wl_display_dispatch_queue_pending ()
    at /usr/lib/libwayland-client.so.0
#11 0x0000743d0b020b5e in ??? ()
    at /usr/lib/libQt6WaylandClient.so.6
#12 0x0000743d097883e4 in QObject::event(QEvent*) ()
    at /usr/lib/libQt6Core.so.6
#13 0x0000743d0a6fbfcb in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt6Widgets.so.6                     
#14 0x0000743d0973dae8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt6Core.so.6                         
#15 0x0000743d0973de74 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/libQt6Core.so.6       
#16 0x0000743d099860e4 in ??? () at /usr/lib/libQt6Core.so.6
#17 0x0000743d094e0199 in ??? () at /usr/lib/libglib-2.0.so.0
#18 0x0000743d0953f3bf in ??? () at /usr/lib/libglib-2.0.so.0
#19 0x0000743d094df712 in g_main_context_iteration ()
    at /usr/lib/libglib-2.0.so.0
#20 0x0000743d09983df4 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt6Core.so.6   
#21 0x0000743d09745c7e in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt6Core.so.6                      
#22 0x0000743d097416e8 in QCoreApplication::exec() ()
    at /usr/lib/libQt6Core.so.6
#23 0x00005cef614cd2ea in ??? ()
#24 0x0000743d09043cd0 in ??? () at /usr/lib/libc.so.6
#25 0x0000743d09043d8a in __libc_start_main ()
    at /usr/lib/libc.so.6
#26 0x00005cef614cdb75 in _start ()

Another issue (present also in @gfgit 's PR if I remember well) : the lxqt-panel.desktop file is missing in /etc/xdg/autostart and therefor no module is seen in lxqt-config-session.

stefonarch avatar Apr 18 '24 05:04 stefonarch

Just checked kwin: no issue with crashing, it crashes only in wlroots-based compositors: tested wayfire, labwc and Hyprland. At login, when configuring (random) and when using F12 which executes

#!/bin/bash
# Helper script for using qterminal -d (dropdown) under wayland
# Add F12 as shortcut in compositor
while IFS= read -r line; do
    qdbus "$line" / org.lxqt.QTerminal.Process.toggleDropdown
done < <(qdbus | grep QTermin | awk '{$1=$1};1')

stefonarch avatar Apr 18 '24 06:04 stefonarch

@stefonarch What about #2043 alone? I want to peg this down in a couple of days. It's strange that we both are using arch, I cannot for any reason make the panel crash.

Well, I'm using Artix/Arch, but I think it should not matter.

marcusbritanicus avatar Apr 18 '24 07:04 marcusbritanicus

@stefonarch What about #2043 alone?

Made a package now for this - working fine on kwin and no crashes on labwc so far.

stefonarch avatar Apr 18 '24 11:04 stefonarch

As already mentioned: if somebody compiles and installs directly it wouldn't be noticed, but if packages are built both from this PR and https://github.com/lxqt/lxqt-panel/pull/2043 the desktop module (aka /etc/xdg/autostart/lxqt-panel) will not be installed and the panel will not start automatically and isn't seen in lxqt-config-session.

Wayland taskbar PRs: screen_area_ven_19:12:28_

Refactor PR which is ok: screen_area_ven_19:12:06_

The issue is probably in the CMakeList.txt from @gfgit 's PR: https://github.com/lxqt/lxqt-panel/pull/2043/files#diff-8d86bd04367459ea2d480ddd870ec392a57368868dcaeec65beda5ef97220bd9

If this is fixed we could have an AUR package to get more testers.

stefonarch avatar Apr 19 '24 17:04 stefonarch

At last, I found time to try this branch. But I saw to task-bar under LabWC, Wayfire or kwin_wayland. I tried several things (a long list), but still no task-bar.

Of course, I know that @stefonarch and @marcusbritanicus have task-bars with this branch (@stefonarch even used my panel config file in terminal and had task-bar, as I tried his compiled package with no effect). There should be a hidden factor.

tsujan avatar Apr 21 '24 16:04 tsujan

OK, I found the cause by looking at the code. It's in the c-tor of LXQtTaskbarWaylandBackend (in the file lxqttaskbarbackendwayland.cpp): it expects XDG_CURRENT_DESKTOP to be the name of the Wayland compositor, while I set it to LXQt under LabWC and Wayfire (to have correct styling with all Qt apps).

The task bar showed up as soon as I started the panel with XDG_CURRENT_DESKTOP=labwc lxqt-panel -c MY_CONF. However, it crashed three times —as @stefonarch reported above, and with a backtrace which isn't informative at all:

#0  0x000055d95ae16fb3 in ??? ()
#1  0x00007f091bf97609 in ??? () at /usr/lib/libQt6Core.so.6
#2  0x000055d95ae1d7b4 in ??? ()
#3  0x00007f091bf97609 in ??? () at /usr/lib/libQt6Core.so.6
#4  0x000055d95ae1b338 in ??? ()
#5  0x00007f091d528596 in ??? () at /usr/lib/libffi.so.8
#6  0x00007f091d52500e in ??? () at /usr/lib/libffi.so.8
#7  0x00007f091d527bd3 in ffi_call () at /usr/lib/libffi.so.8
#8  0x00007f091d924645 in ??? () at /usr/lib/libwayland-client.so.0
#9  0x00007f091d924e73 in ??? () at /usr/lib/libwayland-client.so.0
#10 0x00007f091d92513c in wl_display_dispatch_queue_pending () at /usr/lib/libwayland-client.so.0
#11 0x00007f091d993b5e in ??? () at /usr/lib/libQt6WaylandClient.so.6
#12 0x00007f091bf883e4 in QObject::event(QEvent*) () at /usr/lib/libQt6Core.so.6
#13 0x00007f091cefbfcb in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt6Widgets.so.6
#14 0x00007f091bf3dae8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt6Core.so.6
#15 0x00007f091bf3de74 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
    at /usr/lib/libQt6Core.so.6
#16 0x00007f091c1860e4 in ??? () at /usr/lib/libQt6Core.so.6
#17 0x00007f091bd0d199 in ??? () at /usr/lib/libglib-2.0.so.0
#18 0x00007f091bd6c3bf in ??? () at /usr/lib/libglib-2.0.so.0
#19 0x00007f091bd0c712 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#20 0x00007f091c183df4 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /usr/lib/libQt6Core.so.6
#21 0x00007f091bf45c7e in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt6Core.so.6
#22 0x00007f091bf416e8 in QCoreApplication::exec() () at /usr/lib/libQt6Core.so.6
#23 0x000055d95ad272ea in ??? ()
#24 0x00007f091b843cd0 in ??? () at /usr/lib/libc.so.6
#25 0x00007f091b843d8a in __libc_start_main () at /usr/lib/libc.so.6
#26 0x000055d95ad27b75 in ??? ()

tsujan avatar Apr 21 '24 21:04 tsujan