Support desktop configuration similar to xmonad/herbstluftwm

[ThomasAdam]

Now that we have per-monitor desktops, perhaps it makes sense to consider whether supporting a desktop model such as Xmonad's or herbsfluftwm makes sense. I don't want to emulate dwm's model or awesome whereby you define, say, 10 desktops and assign 1..5 on one monitor, and 6..10 on another, as this has always annoyed me.

The Xmonad documentation details how they handle desktops (which they call workspaces) here: https://xmonad.org/tour.html

I think having a "view" into a desktop which aren't directly attached to any one monitor could be really interesting, and wouldn't be too difficult to support in fvwm3.

[issue-label-bot]

Issue-Label Bot is automatically applying the label enhancement to this issue, with a confidence of 0.91. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[NsCDE]

Hi @ThomasAdam

I'm reading again and again "Using other workspaces" on Xmodad url which you sent, but I cannot find what is the difference between this and FVWM3 per-monitor DesktopConfiguration. Wha am I missing here?

BTW, if we are talking about desk<->monitor modes, I was thinking for a long time about something which can be called "global+presentation" mode: to have primary monitor like in one-monitor setup, and other "presentation" monitor to be independent from the desk/page scheme, so windows can be sent there with commands from menus, shortcuts, moving them by mouse etc ... However, this may significantly alter many parts of the code and commands: MoveToPage, MoveToDesk, StartsOnScreen, GotoPage, GotoDesk, $[desk.n] $[page.nx], $[page.ny] (-1 here?) ...

Just some thoughts ...

[ThomasAdam]

Hi @NsCDE

Unlike in per-desktop where the same number of desktops are copied to each monitor (to be separate from one another), with WMs like xmonad and herbstluftwm, the desktops are separate from the number of monitors, and instead, each monitor can move between them.

So for example, let's say you had the following number of desktops:

0     1      2      3     4

... and let's say that you have two monitors. You might have this:

[0]     1      2      <3>     4

Where [] is monitor1 and <> is monitor2.

You could move monitor1 ([]) all the way along to desktop 2, without changing where monitor2 (<>) is, as in:

0     1     [2]      <3>     4

If you were to then continue to move monitor1 ([]) to desktop 3, what would happen is this:

0     1     <2>      [3]     4

So that now, the desktops have switched over from each monitor.

Another way of expressing this, is monitors become "viewports" in to desktops, rather than desktops being attached to specific monitors.

[NsCDE]

Hi @ThomasAdam

Finally, at the end of explanation I got it. :)

This seems more simple and less visually confusing then per-monitor. Aspect ratio is preserved too. You can even make configuration option if overlaping desks will swap places on monitors as in this example, or go at the next right or left place, or beginning/end of the row if they are already there.

[NsCDE]

Hi @ThomasAdam

One thought I just came on: in such setup, sticky windows (that is, displayed on more than one screen) will be impossible, and should become unsticked across desks when such DesktopConfiguration is applied. This is probably due to X limitation and not doable without compositing, and FVWM and FVWM3 does not compose.
Or am I missing something here?

[ThomasAdam]

Hi @NsCDE

Yes -- that's a good point. It does make sticky windows useless. It doesn't have anything to do with X or compositing. I'm not sure what you're asking.

[NsCDE]

Initially, I was not asking anything, just trying to discuss about this interesting alternative DesktopConfiguration idea. But now, question emerges how sticky windows should be treated in that situation. By sniffing around (I didn't tried personally) Xmonad moves supposed-to-be-sticky windows on monitor where pointer arrives. Maybe FVWM3 can follow that pattern if this kind of desktop configuration is going to be implemented.

[ThomasAdam]

RIght, OK. Well I suppose we could imply the current monitor for sticky windows. Maybe that makes sense.

An easier way of testing this, @NsCDE is to use spectrwm--- it's much more compact than herbswm or xmonad, and demonstrates the concept of this desktop idea out of the box.

[ThomasAdam]

Hi,

If anyone's interested in testing this, I've put together a proof-of-concept patch for this on the ta/shared-desktops branch. To enable it you will need to add this to your configuration:

DesktopConfiguration shared

Note that this WILL NOT WORK with a DesktopSize > 1x1 -- as I have not added code to support moving pages, so if you use a DesktopSize which is anything other than 1x1, paging will not work, and windows on different pages won't be preserved between moving to different desks.

It's probably also going to look strange using a global FvwmPager -- that is, a pager that hasn't been told to look at a specific monitor (*FvwmPager: Monitor xxxx) -- but that's down to how windows are unmapped on unoccupied desktops.

There's still more to do on this, but it's working well enough for me.

Comments welcome!

[lgsobalvarro]

After playing a bit with DesktopConfiguration shared I have notice the following:

1. Iconified windows jump from screen to screen.
I have 4 desks. Screen1 uses 1 and 2, and Screen2 uses 3 and 4.
If I iconify a window in Screen1 Desk1, and then I go to Screen2 and I witch from desktop 3, to 4, the iconified window will show in Desk 4 (Screen2) not in Desk1 (Screen1). If I want this iconified window to return to Screen1 I can switch from desk1 to desk2, there the iconified window is placed where it was originally, and then I can go back to desk1 without issues. This is a minor annoyance. However making sure that DesktopConfiguration shared tracks (and remeber) where iconified windows are, and make sure to keep them there, would be a welcome addition.

2. Maximize windows and screens with different resolutions
If Screen1 and Screen2 have different resolutions and you maximize a window maximization does not work as expected when:
A. When you maximize a window in either screen and then move it across the other screen. Window geometry is not recalculated in order for it to cover the other screen, or to fit in it.
B. When you alter/change witch desktops are handled by Screen. For example: From Screen1 Desk1 and 2. Screen2 Desk3 and 4 to Screen1 Desk3 and 4. Screen2 Desk 1 and 2.

3. Sticky windows only "stick" by screen
This my be done by design, but perhaps would be nice if one could set a sticky window to also show on the other screen.

4. Drag & Drop windows from one desk to another is a bit buggy
The pager seems to have a hard time tracking where a window is after you drag&drop it from a desk handled in one screen to a desk handled y another screen.

[ThomasAdam]

1. Iconified windows jump from screen to screen.
I have 4 desks. Screen1 uses 1 and 2, and Screen2 uses 3 and 4.
If I iconify a window in Screen1 Desk1, and then I go to Screen2 and I witch from desktop 3, to 4, the iconified window will show in Desk 4 (Screen2) not in Desk1 (Screen1). If I want this iconified window to return to Screen1 I can switch from desk1 to desk2, there the iconified window is placed where it was originally, and then I can go back to desk1 without issues. This is a minor annoyance. However making sure that DesktopConfiguration shared tracks (and remeber) where iconified windows are, and make sure to keep them there, would be a welcome addition.

I suppose adding an option for this might make sense -- however, iconified windows are obeying the same rules as non-iconified windows -- they move with the desk.

2. Maximize windows and screens with different resolutions
If Screen1 and Screen2 have different resolutions and you maximize a window maximization does not work as expected when:
A. When you maximize a window in either screen and then move it across the other screen. Window geometry is not recalculated in order for it to cover the other screen, or to fit in it.

This is true in any situation. I'm unsure whether it should -- a window is allowed to be larger than the size of the viewport.

B. When you alter/change witch desktops are handled by Screen. For example: From Screen1 Desk1 and 2. Screen2 Desk3 and 4 to Screen1 Desk3 and 4. Screen2 Desk 1 and 2.

Yeah -- again, you could write a function to handle this. I'm not sure fvwm should be doing this for you.

3. Sticky windows only "stick" by screen
This my be done by design, but perhaps would be nice if one could set a sticky window to also show on the other screen.

I guess I could use StickAcrossDesks.

4. Drag & Drop windows from one desk to another is a bit buggy
The pager seems to have a hard time tracking where a window is after you drag&drop it from a desk handled in one screen to a desk handled y another screen.

Yes. How is your pager configured?

[lgsobalvarro]

I suppose adding an option for this might make sense -- however, iconified windows are obeying the same rules as non-iconified windows -- they move with the desk.

I gather that, however, my iconified windows are set as sticky.

Style * IconSize 48 48
Style * IconBackgroundColorset 10
Style * IconTitleColorset 1
Style * HilightIconTitleColorset 2
Style * IconBox +0 +0 -0 -0, IconFill left bottom
Style * IconBackgroundPadding 5
Style * StickyIcon
Style * !UseIconPosition
Style * !StickyStippledIconTitle

However for whatever reason they do not behave as a normal window with the sticky status.

This is true in any situation. I'm unsure whether it should -- a window is allowed to be larger than the size of the viewport.

Well as far I have seen with KDE, Enlightenment and e16, when you do move a maximized window, it does by default recalculate its geometry to remain maximized according to the new screen size.

Yeah -- again, you could write a function to handle this. I'm not sure fvwm should be doing this for you.

Perhaps an example for the man pages and/or the wiki could be handy :)

Yes. How is your pager configured?

Module FvwmPager Pager1 0 3
Module FvwmPager Pager2 0 3

DestroyModuleConfig Pager1:*
*Pager1: Colorset * 10
*Pager1: HilightColorset * 11
*Pager1: WindowColorsets 1 2
*Pager1: Rows 1
*Pager1: Columns 1
*Pager1: Font "xft:.Lucida Grande UI:size=7:antialias=true"
*Pager1: SmallFont "xft:.Lucida Grande UI:size=4:antialias=true"
*Pager1: MiniIcons
*Pager1: Monitor eDP

DestroyModuleConfig Pager2:*
*Pager2: Colorset * 10
*Pager2: HilightColorset * 11
*Pager2: WindowColorsets 1 2
*Pager2: Geometry 64x192-0+0@HDMI-A-0
*Pager2: Rows 1
*Pager2: Columns 1
*Pager2: Font "xft:.Lucida Grande UI:size=7:antialias=true"
*Pager2: SmallFont "xft:.Lucida Grande UI:size=4:antialias=true"
*Pager2: MiniIcons
*Pager2: Monitor HDMI-A-0`

[ThomasAdam]

Hello all,

I've now updated this to support pages as well as desks. You won't need to do anything -- windows on pages for desks being swapped between monitors, will be handled automatically.... otherwise I've broken something and that's a bug. ;)

Please do retest.

[ThomasAdam]

Hey all,

OK -- so the final version of this is now complete. It's available on the same branch (ta/shared-desktops) and has been rebased against the HEAD of master. Highlights to consider when testing:

• Manpage has been updated (if this could be clearer, let me know. Better still: patches welcome!)
• StartsOnScreen and StartsOnDesk, and SkipMapping now work sensibly in this mode. So for example, if SkipMapping ISN'T set and a window is asked to start on Screen X, Desktop 3 and Desktop3 isn't the current deskop, then Desktop 3 is switched to when a window is mapped.
  • Similarly: Style foo StartsOnScreen X, StartsOnDesk 3, SkipMapping will not switch to Desktop 3, but the window is still assigned to that desk.
• External tooling (such as wmctrl) is likely broken, but this is true of other WMs which operate in this mode, so I am less bothered by this being a blocker for this feature.

Any issues, let me know here. I want to get this merged to master next week, if not sooner.

Thanks all!

[lgsobalvarro]

The last changes broke the pager when, desktop-configuration is set (or changed) to per-monitor.

When you switch between desks the applications get "lost".

You can reproduce this by:

1. Having more than 1 desktop (4 in my case, each one with 4 pages).
2. Setting DesktopConfiguration as per-desktop.
3. Moving from Desk 1 to Desk 2, and then back to Desk 1 (Make sure you have windows/apps in both, to actually see the problem).

You'll notice that the pager still shows your windows, but there are nowhere to be seen. If you open FvwmConsole and type GotoDesk 0 0 you'll get the expected behavior.

I also think that using Shared when you have just 1 Desk and several pages is broken. It behaves in a bizarre way for me.

[ThomasAdam]

Hey @lgsobalvarro

Yes, the pager will only make sense in global mode. As for one one Desk, etc., I think I'll make this option conditional on >1 monitors attached.

[ThomasAdam]

Thanks, @lgsobalvarro

I've fixed the problem with breaking per-monitor mode. Please retest.

[lgsobalvarro]

@ThomasAdam Is not working. It's still broken. Pretty much the same behavior.
I send you via email my config just in case is a particular of the config that breaks per-monitor with this particular branch.

[ThomasAdam]

Hi @lgsobalvarro

Please can you retest? With the latest round of changes on ta/shared-desktops, I think I've:

• Fixed the problems with breaking per-monitor mode (so do please recheck) -- and also if you can, check switching between all three modes: shared, per-monitor, and global via FvwmConsole as this should work fine.
• I've added a check to shared such that if you have just one monitor or just 1 desktop defined (via DesktopName command), then this command will not do anything (and a warning is printed to fvwm_debug().

Thanks!

[lgsobalvarro]

Hi @ThomasAdam
Is still broken. I build it yesterday night and login this morning with my normal config (that means set to per-monitor) and it keeps behaving the same way as it did before when you switch between desks using the pager. Via keybindings works fine.

It's also broken for global, same behavior as with per-monitor.

Shared seems to work fine.

The problem resides somewhere in Pager and the way it changes between desks. Pages are not affected.

[lgsobalvarro]

Hi @ThomasAdam as requested my bare bones config.
config.txt