[very wip] window-rules in support of lxqt-panel

[johanmalm]

Related-to: #768

I'm not sure if this is a good idea, but would appreciate high-level thoughts on it.
Please ignore ugly code, etc - it's the general idea I'm wanting to test.

I can't get lxqt-panel to work on my machine (just get a completely transparent panel - both on labwc and openbox).
Have tested with this little script:

#!/usr/bin/env python3

from PyQt5.QtWidgets import *
from PyQt5.QtCore import *
import sys

class Panel(QWidget):
    def __init__(self):
        super().__init__()
        self.setGeometry(0, 0, 1362, 24)
        self.setWindowTitle('lxqt-panel')

        self.cb = QCheckBox('toggle title', self)
        self.cb.move(20, 0)
        self.cb.toggle()
        self.cb.stateChanged.connect(self.changeTitle)

        self.button = QPushButton("Close", self)
        self.cb.move(100, 0)
        self.button.clicked.connect(lambda:self.close())

        self.show()

    def changeTitle(self, state):
        if state == Qt.Checked:
            self.setWindowTitle('foo')
        else:
            self.setWindowTitle('lxqt-panel')

def main():
    app = QApplication(sys.argv)
    ex = Panel()
    sys.exit(app.exec_())

if __name__ == '__main__':
    main()

[Consolatis]

What is the reason for the new unmanaged_xdg struct?

Couldn't we just (re)parent to the always_on_top_tree directly based on the rule match, same for the SSD?

[jlindgren90]

In the way of high-level thoughts, I have a question: is the end-goal that lxqt-panel (or any other panel for that matter) uses layer-shell? Or are these rules an alternative method to run a (Qt) panel, without layer-shell? What lxqt-panel ends up doing is particularly of interest to me since I would likely follow the same approach with qmpanel.

I can't get lxqt-panel to work on my machine (just get a completely transparent panel - both on labwc and openbox).

Is it possible that the default configuration is in fact an empty, transparent panel? It's been a while since I ran lxqt-panel, but this sounds vaguely familiar.

[Consolatis]

My 2 cents:

From the labwc side I think we can support 2 ways for panels:

• wayland native via wlr-layershell and wlr-foreign-toplevel (and hopefully at some point ext-layershell, ext-foreign-toplevel and ext-workspace if the protocols end up being accepted and implemented in wlroots)
• X11 via @jlindgren90's work on STRUT_PARTIAL + my work on the xdg <-> x11 bridge (both of these won't be available until at least wlroots 0.17)

The window rule thing I personally see with a different goal, not specific to panels: Allow users to do some automation for views based on app_id or title. They can also be used for panels obviously but panels should not rely on them.

[stefonarch]

I've no problems to have the panel visible on labwc.

Is it possible that the default configuration is in fact an empty, transparent panel? It's been a while since I ran lxqt-panel, but this sounds vaguely familiar.

A second panel added is empty, the first one should take it's default config which segfaults afaik due to the desktop switch plugin. Here's a working config, lxqt-panel -c /path/to/panel.conf

Will test the draft as soon as I find time.

Allow users to do some automation for views based on app_id or title. They can also be used for panels obviously but panels should not rely on them.

It's not only the panel in fact: some rules could be very useful for pcmanfm-qt --desktop: always_at_bottom. not_closable, on_all_desktops, fullscreen, exclude from switcher. Before lxqt/pcmanfm-qt#1729 it couldn't be distinguished by title from other windows.

[jlindgren90]

It's not only the panel in fact: some rules could be very useful for pcmanfm-qt --desktop: always_at_bottom. not_closable, on_all_desktops, fullscreen, exclude from switcher.

Isn't that (desktop icons/folder view) also a use-case that layer-shell is meant to serve?

[stefonarch]

Sure, but porting pcmanfm-qt to wayland is in the future.

[stefonarch]

Wow, started from build folder and started my panel, just perfect position.

Some issues though I see. Tooltips at 0,0, and no menu, volume slider, calendar will open, no right click menu to configure it too.

EDIT: right click for single tray app menus works (open still at 0 0)

[stefonarch]

BTW this will work really fine per pcmanfm-qt --desktop (title=pcmanfm-desktop0, always_on_bottom) too, except the right click not working

[johanmalm]

Background:

• use with lxqt #768 (comment)

@Consolatis, @jlindgren90: So, I'm exploring ways to run q5/6/gtk4 applications
in non-standard ways because it seems like their 'full' adoption of layer-shell
is a long way off. I just learnt a bit more about QtLayerShell with qt5 through
@Consolatis's example (#768 (comment)),
but I think (to be confirmed though!) that popup's will be hard.

Yes, of course layer-shell it the preferred method, but if it is going to be
years until that's a reality, then I'm keen to explore options to make it work
now. To get a panel, desktop-client or similar working is technically not that
hard, but we obviously want the solution to stand the test of time, not add
disproportionate complexity, etc etc.

What I hadn't realised until a couple of weeks ago was that
sway/wayfire/hyprland implement window rules (defined in config file and based
on app_id/title) and that kwin assign window roles through a protocol.

So I started thinking about how we could do this without creating a monster
and disappearing down a hole. I'm quite a slow adopter and conceptually I
envisage that window-roles/rules would add a lot of code complexity with
if-statements all over the place (or possibly xdg_toplevel_view inheritance
to abstract some of that away) but nonetheless adding significant complexity.

This PR is an experiment to test a theory that for a panel, desktop-client
(e.g. pcmanfm-qt --desktop) or similar, pretty much all the view
functionality should be turned off for example:

• Ability for user to move or resize window
• Server side decoration
• Foreign top-level handling
• Window stacking and all associated desktop.c stuff
• Window cycling (like alt-tab)

...which led me to think that if we turned traditional window-rules concept on
its head and created a super simple struct to hold the node and node-descriptor
(i.e. xdg_unmanaged) then maybe that could be an <applications> rule as
follows:

<applications>
  <application app_id="lxqt-panel">
    <unmanaged layer="top" />
    <position x="0" y="0" />
  </application>
</applications>

<margins top="30" bottom="0" right="0" left="0" output="WL-1" />

With 'traditional' window-rules we'd have to do some sort of implementation
of position, decor, pin, sticky, skip_taskbar, skip_pager, layer which seems
quite complex and deep - which is why I'm entertaining the idea of a complete
opt out (i.e. position the surface, and that's it).

And, yes - of course it's a manual mini-layer-shell implementation and one
based on configuration rather than a protocol and with a lot less flexibility.

From a user perspective, the main disadvantages is that rc.xml need to be
edited in order to get the panel to work as desired - including setting
<margin> to adjust usable_area and so on.

So, yes, it's a compromise in making labwc usable to communities such as
lxqt without waiting for wider adoption of the layer-shell.

References

sway has the for_window command to implement window rules. See: https://man.archlinux.org/man/sway.5#CRITERIA

It looks like wayfire can also associated rules with events - but I suspect
applying rules on map will be quite sufficient for most use-cases.

Examples of rules include:

• decor (openbox)
• shade - not really relevant because we don't do that anyway 😄
• position (openbox)
  • x
  • y
  • monitor
  • region (did not find this anywhere else, but could be of interest to us)
• size
  • width
  • height
• focus
• desktop
• layer (e.g. above/below). Some call it stay_on_top or stay_on_bottom or similar.
• iconic
• skip_pager
• skip_taskbar (plasma-shell)
• maximized
• fullscreen

X11 Window types:

• _NET_WM_WINDOW_TYPE_NORMAL
• _NET_WM_WINDOW_TYPE_DIALOG
• _NET_WM_WINDOW_TYPE_UTILITY
• _NET_WM_WINDOW_TYPE_TOOLBAR
• _NET_WM_WINDOW_TYPE_SPLASH
• _NET_WM_WINDOW_TYPE_MENU
• _NET_WM_WINDOW_TYPE_DROPDOWN_MENU
• _NET_WM_WINDOW_TYPE_POPUP_MENU
• _NET_WM_WINDOW_TYPE_TOOLTIP
• _NET_WM_WINDOW_TYPE_NOTIFICATION

Kwin plasma-shell roles include:

• normal
• desktop
• panel
• onscreendisplay
• notification
• tooltip
• criticalnotification
• appletpopup

[stefonarch]

@johanmalm Nice writeup and thanks for your efforts!

lxqt-panel is working fine now: sliders, calendar and menu at correct position, only the "configure panel" windows are at 0 0 (this happens on every compositor). As poups are working now the desktop in background layer should be easy.

FYI pcmanfm-qt --desktop works perfectly (except that it's now outside lxqt-session) with the background_view plugin in wayfire.

[background-view]
command = pcmanfm-qt --desktop
app_id = pcmanfm-qt
inhibit_input = false

[stefonarch]

From a user perspective, the main disadvantages is that rc.xml need to be
edited in order to get the panel to work as desired

This will be probably the situation with any compositor, some changes to the default config files are needed. My idea is that in lxqt-session the wayland compositor can be set as now the x11 WM and those configs have to be shipped by LXQt, mostly the window_rules part.

[johanmalm]

Leaving this one open for now, but see #933 for latest development.

[Consolatis]

Is this PR still relevant now that we have window rules?

[johanmalm]

Agree. Will close