use with lxqt #768
Comments
|
For panels all you need is usually
I am not sure about the current state of the wayland support for lxqt-panel. |
|
Lxqt panel works on kwin kwinft they claim because those desktops give
special support and the need for a qt-layer-shell is needed please refer to
the discussion previously posted to see what the developers are saying
about your wm and what is needed to make it usable for lxqt.
…On Fri, Feb 10, 2023, 8:01 AM Consolatis ***@***.***> wrote:
For panels all you need is usually
- the wlr-layershell protocol
- wlr-foreign-toplevel-management protocol
- hopefully at some point in the future the ext-workspace protocol
I am not sure about the current state of the wayland support for
lxqt-panel.
If there are specific issues in regards to labwc feel free to mention them.
—
Reply to this email directly, view it on GitHub
<#768 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOSDAZOAMRK2KJH3HBMV7KLWWZQ45ANCNFSM6AAAAAAUX6EUPQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I am sorry but I will not read through a general wayland support issue with > 400 comments and search for (possibly long fixed) issues with labwc. But again, feel free to mention specific things that are still broken on the latest master branch or labwc 0.6.1. |
|
okay i will do my best to try to summarize the info for you for its
actually a big issue.
according to the following work and info of using lxqt de on wayland and
working with your labwc wm project.
https://github.com/stefonarch/LXQt-Wayland-files
with qt apps the wlr-layershell does not allow auto placement and since
theres no window rules it makes qt placement and access of layershell not
possible. and like sfwbar go past the screen and make the ability to use a
menu not functional as well as the no automatic placement of app windows. i
do apologize but i am not a programmer and so trying to help you by
facilitate information on the problems when i dont understand all the terms
my self is difficult. and thought providing the links to discussions why
developers are saying your wm isnt usable yet would be helpful if the
information i am trying to provide isn't useful i am sorry for wasting your
time. but in x11 my only use for openbox was to integrate it onto lxqt and
to be honest that is the only use i would have for your project as well i
get hitting a button to go to the bottom of the page and read the current
state of things and staying up-to-date on the discussion may be to much for
you but feel very insulted by your reluctance to work on obviously blatant
issues
…On Fri, Feb 10, 2023 at 8:12 AM Consolatis ***@***.***> wrote:
I am sorry but I will not read through a general wayland support issue
with > 400 comments and search for (possibly long fixed) issues with labwc.
But again, feel free to mention specific things that are still broken on
the latest master branch or labwc 0.6.1.
—
Reply to this email directly, view it on GitHub
<#768 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOSDAZO2VXIFGHW4QLUQPTTWWZSFFANCNFSM6AAAAAAUX6EUPQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
We support the wlr-layershell protocol and (as far as I know) it works just fine as can be seen by various panels and notification daemons. I can't say anything about the Qt implementation of the layershell protocol or LxQt's usage of the protocol.
This is true, we do not support automatic placement of windows but that is also absolutely not required for desktop components that use the layershell protocol, they can just dock to some edges and get positioned automatically (or provide a traditional desktop background).
That is totally fine and actually the expected way to use labwc.
What does a panel not (yet) implementing scroll support for menus have to do with labwc? |
|
I've not studied the specifics of quoted threads, so am answering quite generically. I don't think Qt popups work with the layer-shell protocol. I might be wrong on this, but from memory I think that was concluded on #sway-devel. Not sure of technical reasons. I wrote a quick proof-of-concept QtLayerShell panel (https://github.com/johanmalm/tint) to get my head around how it works, and concluded that it only supports Qt's QWindow (or QRasterWindow) rather than QWidgets, QGraphicsScene and so on. This is still pretty powerful if you're writing a panel from scratch, but probably not that helpful if you're porting an existing one with QWidgets. @jlindgren90 runs a Qt panel (https://github.com/jlindgren90/qmpanel) on labwc but I think it uses XWayland. That might be a useful reference point for helping port the lxqt-panel. |
|
https://github.com/stefonarch/LXQt-Wayland-files quotes "No window rules with version 0.6, lxqt-panel not usable (manual placement)" Do they mean |
This seems to be a conflict between gtk and gtk-layer-shell and I expect it affects all applications using gtk-layer-shell. This is not a labwc issue. I was able to reproduce this on other compositors supporting the layer shell protocol. See LBCrion/sfwbar#75 |
|
here is an attachment of my configs with setup notes
for nwg-shell
sfwbar
and much more
and wayland based apps that run and help complete desktop including tray
icons
and commands for increased stability when working with n gtk and qt apps
…On Fri, Feb 10, 2023 at 8:42 PM LBCrion ***@***.***> wrote:
and like sfwbar go past the screen and make the ability to use a menu not
functional
What does a panel not (yet) implementing scroll support for menus have to
do with labwc? If you are referring to usual window menus I am starting to
think that your desktop components do not actually use wayland at all.
This seems to be a conflict between gtk and gtk-layer-shell and I expect
it affects all applications using gtk-layer-shell. This is not a labwc
issue. I was able to reproduce this on other compositors supporting the
layer shell protocol. See LBCrion/sfwbar#75
<LBCrion/sfwbar#75>
—
Reply to this email directly, view it on GitHub
<#768 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOSDAZNUE3BKGPF2P4VNTTDWW4KEVANCNFSM6AAAAAAUX6EUPQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Yes: lxqt/lxqt#10 (comment) |
|
It feels like we need to get back to basics and do some requirements management here. User RequirementKey points from me:
I'd appreciate thoughts on the above before going much further, but will offer some quick thoughts on possible implementation approaches to help think through where to land system requirements. System Requirements - High Level OptionsOption AAllow setting positions and roles via a protocol. Adoption of new protocols is pretty slow, so whilst this would be neat, it's likely to be a very long way home. I'm not sure how lxqt-panel positions the window and assigns a role under kwin. If anyone knows, I'd appreciate a pointer. plasma-shell does allow setting of position + role, but I can't find documentation of what different roles actually mean, so I guess it's pretty internal to plasma. We adhere to a project principle to only use Wayland/wlroots protocols and not implement others in the interest of Wayland adoption (through less fragmentation). Now, wlroots already includes at least two KDE protocols (idle + server-decoration), so guess we could do some soul searching here if it turns out to be the best and most helpful way of dealing with this. Option BAllowing configuration of labwc window-rules to allow setting of position and role. Openbox 3.6 specification describes window rules through the For comparison, I haven't discussed this with @Consolatis and @jlindgren90 yet, but suppose this option might be a more in keeping with our general approach. From a user perspective, the main disadvantage is that Panel RoleRegardless of option A, B or some other approach, I think we'd have to create a whole new object class because it couldn't be handled as a layer-shell client without supporting the layer-shell protocol and we wouldn't want it to be exactly like an xdg-toplevel-view. Positioning of a panel should be pretty straight forward (and even the adjustment of 'usable area') but the behaviur of a panel is likely to be deeper. Thinking off the top of my head, a panel would probably want to inherit the xdg-toplevel-view-implementation (=method dispatch), but:
Side note 1: These two topics could be of interest http://openbox.org/wiki/Help:Configuration#Dock and http://openbox.org/wiki/Help:Configuration#Margins Side note 2: There is a related issue on decoration protocols ( |
|
Nice write-up. We do have an always-on-top tree for views already, we could add an always-on-bottom tree as well. So the
If coupled with some positioning magic, that could take care of desktop background / icon implementations. Dealing with decorations should already be doable, see The obvious alternative here is the ext-layer-shell protocol MR and an implementation thereof in Qt (base or external module). Another alternative for the panel would be to just run the panel via xwayland and try to get #625 implemented. This still doesn't solve the missing foreign-toplevel support for the panel though, e.g. how to actually list the applications. In my opinion we should not start to implement features only to enhance usability of the current LXQt components alone. I am personally not really a fan of the If I would be in LXQt's shoes I would likely either
Edit: |
For now, we don't add Wayland-specific codes (as we've always avoided X11-specific codes as far as possible), relying on Qt's Wayland support as well as on what can be expected from all Wayland compositors/WMs. What we've done — and will continue to do — is making the codes work with Wayland in general (see lxqt/lxqt#2357). That has been done completely for As for |
On all 4 compositors I'm running the panel as it is (without desktop-switcher)
Some compositors do 3. without rules. I'm not running kwin with plasmashell.
But on the positive side we have an application menu, tray, movable widgets, icons and panel size, quicklaunch with DND, and the powerful custom command plugin (display keyboard layout, numpad state, active workspace ecc ) , folder view, clock and calendar and some other monitor widgets - all configurable without fiddling with config files and restarting it. Much appreciating for you all looking into this. |
For labwc (and possibly other compositors that support the wlr-layershell protocol) you could try something like this: #!/usr/bin/env python3
import gi
gi.require_version("Gtk", "3.0")
gi.require_version('GtkLayerShell', '0.1')
from gi.repository import Gtk, GtkLayerShell
if __name__ == '__main__':
win = Gtk.Window()
win.set_size_request(-1, 26)
GtkLayerShell.init_for_window(win)
GtkLayerShell.auto_exclusive_zone_enable(win)
GtkLayerShell.set_anchor(win, GtkLayerShell.Edge.LEFT, True)
GtkLayerShell.set_anchor(win, GtkLayerShell.Edge.RIGHT, True)
GtkLayerShell.set_anchor(win, GtkLayerShell.Edge.TOP, True)
GtkLayerShell.set_layer(win, GtkLayerShell.Layer.BOTTOM)
win.show()
Gtk.main()And then move the panel on top. Some compositors might interpret the Edit:
Hm.. I would potentially be up for a small hack regarding this if @johanmalm agrees, e.g. defining some kind of app id that means "don't show in Edit 2: |
|
Nice hack, tested it on labwc but lxqt-panel (with "no decoration, stay on top) flips to the bottom when released somewhere in the white space. And yes:
EDIT: it works perfectly on hyprland , sway and wayfire, but as described unfortunately not on labwc ( |
On wayfire/sway/hyprland, do you use window-rules to get it to work. If so, would you mind posting your configs to help me think through approaches. Assume you get the problems listed above with wayfire/sway/hyprland? One approach would be to turn |
That is solved now by the script from @Consolatis (you can move a floating window also out of screen), but maximized windows don't go under it anymore.
hyprland: wayfire; sway:
Full configs are here: https://github.com/stefonarch/LXQt-Wayland-files/tree/main/lxqt-wayland |
|
Seems like window-rules can be quite useful 😄 Appreciate comments on PR #787 It's a slightly different idea to the window rules in wayfire/hyprland/sway/kwin in that it merely converts an It doesn't show up in the alt-tab dialogue which is a good start. x/y positioning, usable_area, margins, recording.webm |
|
In case somebody wants to experiment with layer-shell-qt: #include <QApplication>
#include <QMainWindow>
#include <QPushButton>
#include <LayerShellQt/shell.h>
#include <LayerShellQt/window.h>
int main(int argc, char **argv) {
QApplication app(argc, argv);
LayerShellQt::Shell::useLayerShell();
QMainWindow main_window;
QPushButton button;
button.setText("foobar");
main_window.setCentralWidget(&button);
/* Ensure platform window is created */
main_window.winId();
QWindow *window = main_window.windowHandle();
LayerShellQt::Window *layershell = LayerShellQt::Window::get(window);
layershell->setAnchors({
LayerShellQt::Window::Anchor::AnchorTop,
LayerShellQt::Window::Anchor::AnchorLeft,
LayerShellQt::Window::Anchor::AnchorRight
});
layershell->setLayer(LayerShellQt::Window::Layer::LayerBottom);
layershell->setExclusiveZone(30);
main_window.resize(0, 30);
main_window.show();
return app.exec();
}
|
Nice! Works well with |
I haven't tried it myself, but I get the impression that popups may not be implemented yet by qt-layer-shell. From https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/28#note_1361484:
|
|
I tried |
|
layer-shell-qt is implemented a bit different to the GTK variant from what I could see. With the GTK variant one creates a window, then give that window to a gtk-layer-shell function which then does the wrapping. This results in control of what windows are actual layershell clients and which are not. In the Qt variant instead it seems one is supposed to enable it for the whole application so all future windows seem to be layershell clients. I am not sure if that could be changed to work on a per-window basis as the GTK implementation and if that would help fix things. Regarding the layer: I am usually using the bottom layer + exclusive zone for panels. |
Exactly. And that's a big problem. To me, the irony is that, while GNOME tries to make GTK a GNOME-only toolkit,
No, but I attach the patch that I used. It may need a small change to be applicable to the git branch but is very simple. Also, this can be added to it: layershell->setScope(QStringLiteral("lxqt-panel"));Edit by Consolatis: diff from the zipdiff -ruNp lxqt-panel-orig/CMakeLists.txt lxqt-panel/CMakeLists.txt
--- lxqt-panel-orig/CMakeLists.txt
+++ lxqt-panel/CMakeLists.txt
@@ -42,6 +42,7 @@ find_package(Qt5Xml ${REQUIRED_QT_VERSIO
find_package(KF5WindowSystem ${KF5_MINIMUM_VERSION} REQUIRED)
find_package(lxqt ${LXQT_MINIMUM_VERSION} REQUIRED)
find_package(lxqt-globalkeys-ui ${LXQT_GLOBALKEYS_MINIMUM_VERSION} REQUIRED)
+find_package(LayerShellQt REQUIRED)
# Patch Version
set(LXQT_PANEL_PATCH_VERSION 0)
diff -ruNp lxqt-panel-orig/panel/CMakeLists.txt lxqt-panel/panel/CMakeLists.txt
--- lxqt-panel-orig/panel/CMakeLists.txt
+++ lxqt-panel/panel/CMakeLists.txt
@@ -104,6 +104,7 @@ target_link_libraries(${PROJECT}
${QTX_LIBRARIES}
KF5::WindowSystem
${STATIC_PLUGINS}
+ LayerShellQtInterface
)
install(TARGETS ${PROJECT} RUNTIME DESTINATION bin)
diff -ruNp lxqt-panel-orig/panel/lxqtpanel.cpp lxqt-panel/panel/lxqtpanel.cpp
--- lxqt-panel-orig/panel/lxqtpanel.cpp
+++ lxqt-panel/panel/lxqtpanel.cpp
@@ -49,6 +49,9 @@
#include <XdgIcon>
#include <XdgDirs>
+#include <LayerShellQt/shell.h>
+#include <LayerShellQt/window.h>
+
#include <KWindowSystem/KWindowSystem>
#include <KWindowSystem/NETWM>
@@ -175,6 +178,10 @@ LXQtPanel::LXQtPanel(const QString &conf
setWindowTitle(QStringLiteral("LXQt Panel"));
setObjectName(QStringLiteral("LXQtPanel %1").arg(configGroup));
+ bool underWayland = QGuiApplication::platformName() == QStringLiteral("wayland");
+ if (underWayland)
+ LayerShellQt::Shell::useLayerShell();
+
//LXQtPanel (inherits QFrame) -> lav (QGridLayout) -> LXQtPanelWidget (QFrame) -> LXQtPanelLayout
LXQtPanelWidget = new QFrame(this);
LXQtPanelWidget->setObjectName(QStringLiteral("BackgroundWidget"));
@@ -234,6 +241,21 @@ LXQtPanel::LXQtPanel(const QString &conf
// NOTE: Some (X11) WMs may need the geometry to be set before QWidget::show().
setPanelGeometry();
+ if (underWayland)
+ {
+ winId();
+ if (QWindow* win = windowHandle())
+ {
+ if (LayerShellQt::Window* layershell = LayerShellQt::Window::get(win))
+ {
+ layershell->setLayer(LayerShellQt::Window::Layer::LayerTop);
+ LayerShellQt::Window::Anchors anchors = {LayerShellQt::Window::AnchorTop};
+ layershell->setAnchors(anchors);
+ layershell->setKeyboardInteractivity(LayerShellQt::Window::KeyboardInteractivityOnDemand);
+ }
+ }
+ }
+
show();
// show it the first time, despite setting |
Oh, I think I got that wrong, you mean tooltips and friends are layershell clients and fullscreen themselves. So if that doesn't get overwritten before the first Edit: |
Yes, that's the default, but the default isn't the problem. The problem is that every window of your app is affected, while you want to put a specific window (usually, the main window) on a layer and leave the others to the WM.
I'll take a look at it. Thanks! EDIT: Sadly, that branch can't even be compiled. |
|
See #933 Doing |
|
On another note, it seems https://invent.kde.org/plasma/layer-shell-qt/-/merge_requests/25 that allows to have xdg-shell and layershell windows within the same application has been merged but I didn't look into it nor tested it. |
|
Dropping an update here, all looks quite promising, taskbar should come also for labwc and other compositors: |
|
This has been an amazing thread, but I feel it's served its purpose. Suggest we close and open new issues for specific things? |
i am working on my system and really hate kwin and even kwinft.. and i would love to use the full lxqt list of applications using your de but the lxqt-panel doesn't load the way sfwbar waybar or any of the gtk based wayland bar apps run on your wm project. the following link will give you info why the lxqt team is having issues with using you wm as a wayland replacement for openbox on x11.
lxqt/lxqt#10 (comment)
The text was updated successfully, but these errors were encountered: