Testing this "lxqt" branch, but somehow I get nothing of the 3 to work: waybar and switcher show still pcmanfm--desktop0 and clicking on the desktop moves it in front "closing" smaller windows. Am I missing something?

  <windowRules>
      <windowRule identifier="lxqt-panel">
        <action name="MoveToEdge" direction="up" />
      </windowRule>

    <windowRule title="pcmanfm-desktop*" skipTaskbar="yes" skipWindowSwitcher="yes">
      <action name="ToggleAlwaysBelow"/>
      <action name="Maximize"/>
    </windowRule>


  </windowRules>

The lxqt branch is 0.4.0.770.g1424542 while 0.6.1.60.g93aff4e is the master branch; the first rule works fine.

Testing this "lxqt" branch, but somehow I get nothing of the 3 to work: waybar and switcher show still pcmanfm--desktop0 and clicking on the desktop moves it in front "closing" smaller windows. Am I missing something?

Weird. Not sure why.

You've got two hyphens in the title (pcmanfm--desktop0). Is that a typo? If not that might be why the window rule doesn't pick it up. Guess you could try pcmanfm*desktop*.

If that doesn't work, try applying this patch to see what the app_id + title actually are on map.

diff --git a/src/view-impl-common.c b/src/view-impl-common.c
index 32f1e39..6f17813 100644
--- a/src/view-impl-common.c
+++ b/src/view-impl-common.c
@@ -46,6 +46,9 @@ view_impl_map(struct view *view)
 			wlr_foreign_toplevel_handle_v1_destroy(view->toplevel.handle);
 		}
 	}
+	fprintf(stderr, "XXX app_id=%s, title=%s\n",
+			view_get_string_prop(view, "app_id"),
+			view_get_string_prop(view, "title"));
 }
 
 static bool

You've got two hyphens in the title

that was a typo, the rule (c&p up here) should be ok.

...to see what the app_id + title actually are on map.

XXX app_id=pcmanfm-qt, title=pcmanfm-desktop0
But app-id and title should be ok too, they were always like that on every compositor, and skip rules do not work for lxqt-panel too while MovetoEdge does.

Install is correct?

git clone https://github.com/johanmalm/labwc.git
cd labwc
git checkout lxqt
meson setup build
ninja -C build install

Install is correct?

git clone https://github.com/johanmalm/labwc.git
cd labwc
git checkout lxqt
meson setup build
ninja -C build install

Try running it from the build directory. That rules out that it's the wrong binary that you're running.
(if you run type labwc it tells you which binary it would run - but it's simpler to just run the build dir).

git clone --branch=lxqt https://github.com/johanmalm/labwc.git
cd labwc
meson setup build
meson compile -C build
./build/labwc -s 'pcmanfm-qt --desktop'

Okeey, it was my startup script. I didn't test labwc for some time and forgot that it started it directly from the build folder without installing it and not from /usr/local/bin - that was a workaround months ago for some wlroots conflict. Anyway, everything works perfectly, even

<windowRule identifier="lxqt-panel" skipTaskbar="yes" skipWindowSwitcher="yes">

"maximize" isn't needed IMO.

Okeey, it was my startup script. I didn't test labwc for some time and forgot that it started it directly from the build folder without installing it and not from /usr/local/bin - that was a workaround months ago for some wlroots conflict. Anyway, everything works perfectly, even

Hey - we must have typed at the same time 😄
...same conclusion.

Yeah, we were. Is it possible to set layers e/o roles in theory with labwc? Anyway, for pcmanfm this approach works fine, thanks!

"maximize" isn't needed IMO.

It might be required if you have another panel that uses the proper layershell protocol, it basically should make sure that it only uses the usable space that is not exclusively used by a panel. If pcmanfm-qt request maximized state itself that should also be fine but requesting the output dimensions would cause issues.

The same will be true once some Margin property is implemented as it will work basically the same way as having a panel with exclusive zone set.

"maximize" isn't needed IMO.

Well, if you have a panel in the bottom layer (which I do) then the desktop hides it.

There is another advantage of maximize which is that it takes into account the usable-area (i.e. the area not taken up by exclusive layer-shell clients). For this to be beneficial with pcmanfm-qt we'd have to explore changing its source code to work with the window size rather than the screen size.

We can make it work without maximize, but it relies on the user setting the pcmanfm-qt margins. Say for example that the user open a new panel (like waybar)... it would be nice if the pcmanfm-qt desktop icons just automatically rearranged themselves.

I can have a look at the pcmanfm-qt code to see if I can figure something out - but will have to be another day.

Sorry, maximize for the desktop I meant, but yes, I see.

The same will be true once some Margin property is implemented as it will work basically the same way as having a panel with exclusive zone set.

Exactly. Without the maximize approach this will get increasingly hacky. Just building on what @Consolatis said - imagine if we have a top-aligned lxqt-panel and implement <margin> to make sure windows take into account the panel, then the pcmanfm-qt --desktop window would be moved vertically down, so the user would have to set the pcmanfm-qt bottom margin to allow for a panel at the top..... it'll be too confusing for people.

It might be this line https://github.com/lxqt/pcmanfm-qt/blob/8a7e4b6d6b37e5db619356a3bacd476e3683312c/pcmanfm/desktopwindow.cpp#LL1332 ... but could lead to regressions

@stefonarch
Any idea how we avoid using a virtual desktop so that we get a pcmanfm-qt --desktop window for each screen?
https://github.com/lxqt/pcmanfm-qt/blob/8a7e4b6d6b37e5db619356a3bacd476e3683312c/pcmanfm/application.cpp#L460-L473

No idea about that, you may ask @tsujan, I've never had any dual monitor setup.

Just noticed that

      <windowRule identifier="lxqt-panel" skipTaskbar="yes" skipWindowSwitcher="yes">
        <action name="MoveToEdge" direction="up" />
        <action name="ToggleAlwaysOnTop"/>
      </windowRule>

makes the panel sticky also on all desktops (thought there is no such action atm). Probably also "region" can be used well for the notifications

Any idea how we avoid using a virtual desktop so that we get a pcmanfm-qt --desktop window for each screen?

If by desktop window you mean the wallpaper, check this box:

Otherwise, the desktop window is treated like any other window, i.e., as a single window.

makes the panel sticky also on all desktops (thought there is no such action atm).

@stefonarch Yes, ToggleAlwaysOnTop is a compound action which both sends the window to the top layer and makes it sticky.

-- EDITED -- Actually - in Openbox the ToggleAlwaysOn{Top,Bottom} do not invoke sticky (or OmniPresent is they call it). Will sort this out separate from this PR.

We ought to make this clear in the manual and we should consider adding SendToLayer (same as Openbox) and possibly ToggleSticky. That would make the C implementation cleaner too which is a bonus.

Otherwise, the desktop window is treated like any other window, i.e., as a single window.

@tsujan I'm not really pushing in any particular direction, I'm just experimenting and learning at the moment.

I'm more interested in the icons. Let me share an observation 😄

If I apply the patch below and implement a rule which moves pcmanfm-desktop1 (the second instance) to the co-ordinates of my second output I get the first screenshot below. We could easily do a per-title window-rule to send instances to a particular output.

diff --git a/pcmanfm/application.cpp b/pcmanfm/application.cpp
index 1a034fc..bfbc86c 100644
--- a/pcmanfm/application.cpp
+++ b/pcmanfm/application.cpp
@@ -460,7 +460,8 @@ void Application::desktopManager(bool enabled) {
             // NOTE: there are two modes
             // When virtual desktop is used (all screens are combined to form a large virtual desktop),
             // we only create one DesktopWindow. Otherwise, we create one for each screen.
-            if(primaryScreen() && primaryScreen()->virtualSiblings().size() > 1) {
+	    if (0) {
+//            if(primaryScreen() && primaryScreen()->virtualSiblings().size() > 1) {
                 DesktopWindow* window = createDesktopWindow(-1);
                 desktopWindows_.push_back(window);
             }
@@ -468,6 +469,7 @@ void Application::desktopManager(bool enabled) {
                 int n = qMax(allScreens.size(), 1);
                 desktopWindows_.reserve(n);
                 for(int i = 0; i < n; ++i) {
+		    qDebug("createDesktopWindow()");
                     DesktopWindow* window = createDesktopWindow(i);
                     desktopWindows_.push_back(window);
                 }

If running pcmanfm-qt --desktop with no patches applied, I get this:

So, I'm just thinking that if there was an option to choose the second branch of that if statement and if pcmanfm-qt --desktop worked off the window geometry - rather than the screen geometry - for things like icon positions, then we have a pretty flexible solution.

I'm not really considering any regressions, etc. (just playing)

Also, please bear in mind that I've spent a lot of time thinking about layer-shell implementations which are output based (not designed to have one big surface spanning multiple outputs), so my head is rightly or wrongly stuck in that space at the moment.

I'm more interested in the icons.

People use multiple screens to extend their work area.

Duplicating items inside the same widget would be a bug. Adding multiple widgets for multiple screens and making multiple copies of each item would be counter-intuitive — to say nothing of the complex code, which also contradicts lightweightness.

BTW, If layer-shell-qtbecomes what is advertised at https://invent.kde.org/plasma/layer-shell-qt/-/merge_requests/25, the desktop of the Qt6 version of pcmanfm-qt should logically be able to put itself on the background layer, anchored to the four screen edges.

I'm more interested in the icons.

People use multiple screens to extend their work area.

Duplicating items inside the same widget would be a bug. Adding multiple widgets for multiple screens and making multiple copies of each item would be counter-intuitive — to say nothing of the complex code, which also contradicts lightweightness.

BTW, If layer-shell-qtbecomes what is advertised at https://invent.kde.org/plasma/layer-shell-qt/-/merge_requests/25, the desktop of the Qt6 version of pcmanfm-qt should logically be able to put itself on the background layer, anchored to the four screen edges.

Understood.

Yes, the layer-shell-qt MR looks promising.

Yes, the layer-shell-qt MR looks promising.

I hope it'll work with all wlroots-based compositors. Its Qt5 version "worked" with them (I'd tested it) but terribly ;) because it put the whole app on a layer — its menus and tooltips too! Perhaps the reason was Qt5 itself.

All review comments processed.

Suggest dealing with 'sticky' in a separate PR.

Original Post updated. Note:

• s/ToggleAlwaysBelow/ToggleAlwaysOnBottom/
• I think this will work best without Maximize and just let pcmanfm-qt --desktop use the whole work area.

I think this will work best without Maximize and just let pcmanfm-qt --desktop use the whole work area.

Right, there's no need to maximization.

I'm not familiar with the code of labwc but, months ago, I did it for the stable version of Wayfire by making personal patches for (1) setting the layer, (2) setting stickiness, and (3) preventing chosen windows (e.g., the desktop) from being raised when focused (by clicking).

EDIT: Sorry, my mistake — after months, I've forgotten many things. The no-raise property was for another purpose..

LGTM, did not have time to test.

Updated and tested again, all working fine.

Thanks all for the help. Another step forward 😄

Thanks to you! Using now labwc as daily driver.
Updated https://github.com/stefonarch/LXQt-Wayland-files#labwc-stacking

Wondering if there is some irc or matrix or whatever channel to discuss, ask questions on the fly etc?

Wondering if there is some irc or matrix or whatever channel to discuss, ask questions on the fly etc?

#labwc @ libera

Only noticed now: copy|move popup and file tooltips info do not appear on the desktop (moving a file into a folder for example should be like that):

It's impossible without using a shortcut (ctrl or shift) to move files into a folder.

Tooltips appear when clicking the empty desktop first.

Only noticed now: copy|move popup and file tooltips info do not appear on the desktop (moving a file into a folder for example should be like that)
It's impossible without using a shortcut (ctrl or shift) to move files into a folder.
Tooltips appear when clicking the empty desktop first.

Those drag-and-drop popups work for me when dragging to pcmanfm-qt --desktop from nautilus, thunar and pcmanfm-qt - but interestingly it does not work from pcmanfm (without -qt).

It looks like it's not related to the desktop implementation or our window-rules because I can't drag-and-drop between pcmanfm-qt and pcmanfm either (both without --desktop).

Which application did you drag from?

Which application did you drag from?

It's about dragging from the desktop itself: a file or folder into a folder.

EDIT: yes, from a pcmanfm-qt window it works as expected.

Oh - I see. Got it. That's weird!

Only noticed now: copy|move popup and file tooltips info do not appear on the desktop (moving a file into a folder for example should be like that):

It's impossible without using a shortcut (ctrl or shift) to move files into a folder.

Tooltips appear when clicking the empty desktop first.

Have raised #939 so that we don't lose this one.