Consider virtual desktop integration/features

[andrewdavidwong]

See this discussion thread:

https://groups.google.com/d/topic/qubes-users/gCklOzk9xYg/discussion

[evadogstar]

The issue does not describe the problem and what need to do. After reading linked disscussion thread I found that users want some tool to manage windows on the screen and at the virtual desktops. I also think that it's "must have" option.

[evadogstar]

The issue does not describe the problem and what need to do. After reading linked disscussion thread I found that users want some tool to manage windows on the screen and at the virtual desktops. I also think that it's "must have" option.

[unman]

I think Andrew had it right in that thread - some users want a tool, and with respect @evadogstar , it's not "must have", not even a "must have option". You, perhaps, must have it, but many people will manage perfectly without it.
In my experience many users wont use virtual desktops and find them confusing. If Qubes were to enforce their use it would, I think,reduce uptake.

[unman]

I think Andrew had it right in that thread - some users want a tool, and with respect @evadogstar , it's not "must have", not even a "must have option". You, perhaps, must have it, but many people will manage perfectly without it.
In my experience many users wont use virtual desktops and find them confusing. If Qubes were to enforce their use it would, I think,reduce uptake.

[evadogstar]

I tried to install devilspie2 for testing purposes on Qubes. Currently, it's not work on Qubes.
Devilspie2 function get_window_name() return Windows names without AppVM labels. Therefore, it's not possible to sort windows on desktops by AppVM name.
UPDATE: my mistake. With get_class_instance_name() it works without patching.

[evadogstar]

I tried to install devilspie2 for testing purposes on Qubes. Currently, it's not work on Qubes.
Devilspie2 function get_window_name() return Windows names without AppVM labels. Therefore, it's not possible to sort windows on desktops by AppVM name.
UPDATE: my mistake. With get_class_instance_name() it works without patching.

[jpouellet]

@evadogstar If you want to make it work, you may need to patch it to inspect the X props set by Qubes.

[jpouellet]

@evadogstar If you want to make it work, you may need to patch it to inspect the X props set by Qubes.

[tonsimple]

@unman
I tend to think that having ability to restrict a VM to a specific (xfce) desktop (as "place where app can spawn a window", perhaps with option for stricter restriction) would be extremely useful and would nicely extend the ways by which user with many VMs having many different windows can semi-reflexively distinguish VMs.

It might not be a "must" have feature (I am having >10 active, "window-having" VMs and well, I'm mostly okay, alive and writing this from my Qubes workstation) but it would make life of users like me easier.

Right now I spend 2-5 minutes starting up applications and carefully, very carefully sending windows to their "supposed" desktops (and then drag each to it's supposed monitor, yes, I am running a dual-head setup)

It's not the worst thing in the world, but if I could just, like, set "windows from [LAN-work-VM] only can appear on desktop 2 when application starts, AND can be sent to other desktop, while windows from [router-man-VM] can only appear at desktop 6 when application starts, AND CAN NOT leave that desktop, ever", that would be absolutely awesome for me (and I suspect for any user who run a lot of different GUI stuff in >10 different VMs)

[tonsimple]

@unman
I tend to think that having ability to restrict a VM to a specific (xfce) desktop (as "place where app can spawn a window", perhaps with option for stricter restriction) would be extremely useful and would nicely extend the ways by which user with many VMs having many different windows can semi-reflexively distinguish VMs.

It might not be a "must" have feature (I am having >10 active, "window-having" VMs and well, I'm mostly okay, alive and writing this from my Qubes workstation) but it would make life of users like me easier.

Right now I spend 2-5 minutes starting up applications and carefully, very carefully sending windows to their "supposed" desktops (and then drag each to it's supposed monitor, yes, I am running a dual-head setup)

It's not the worst thing in the world, but if I could just, like, set "windows from [LAN-work-VM] only can appear on desktop 2 when application starts, AND can be sent to other desktop, while windows from [router-man-VM] can only appear at desktop 6 when application starts, AND CAN NOT leave that desktop, ever", that would be absolutely awesome for me (and I suspect for any user who run a lot of different GUI stuff in >10 different VMs)

[jpouellet]

How is this intended to work for people with many more VMs than it makes sense to have virtual desktops? I have dozens. Is this case covered, or is it expected that users will have few (say, less than 10 or so) VMs?

[jpouellet]

How is this intended to work for people with many more VMs than it makes sense to have virtual desktops? I have dozens. Is this case covered, or is it expected that users will have few (say, less than 10 or so) VMs?

[jpouellet]

Or is the idea to create & destroy virtual desktops dynamically as VMs are started & stopped?

[jpouellet]

Or is the idea to create & destroy virtual desktops dynamically as VMs are started & stopped?

[tonsimple]

@jpouellet
Well, any solution for "many VM" issue will be limited (I for one would like to have more colors and patterns, too, my peak VM count was closer to 20) because there are only so many meaningful markers you can have (and remember)
Having some more colors AND customizable patterns would be great help too :-)

Right now I do the following:

Each window can "belong" (belonging determined by me, at every startup, which is clumsy) to a monitor on a virtual desktop (I have two monitors)

Windows from different VMs that share a color (windows7 vm shares color with my LAN-browsing VM, both yellow) should avoid showing up on same desktop

So I send windows to different desktops in accordance to which VM they belong to manually, avoiding "color collisions" (most of the times I manage that, but at "Peak VM" I had several "red" windows from different VMs sharing a desktop because there was just too-much-stuff)

After that I carefully place windows to different monitors within each desktop (thankfully chromium and firefox seem to remember window relative position, so they tend to spawn in the "correct monitor" most of the time)

edit
P.S.:
I have 6 virtual desktops and am considering buying one more monitor... not sure Qubes+InteIGFX can handle that tho...

[tonsimple]

@jpouellet
Well, any solution for "many VM" issue will be limited (I for one would like to have more colors and patterns, too, my peak VM count was closer to 20) because there are only so many meaningful markers you can have (and remember)
Having some more colors AND customizable patterns would be great help too :-)

Right now I do the following:

Each window can "belong" (belonging determined by me, at every startup, which is clumsy) to a monitor on a virtual desktop (I have two monitors)

Windows from different VMs that share a color (windows7 vm shares color with my LAN-browsing VM, both yellow) should avoid showing up on same desktop

So I send windows to different desktops in accordance to which VM they belong to manually, avoiding "color collisions" (most of the times I manage that, but at "Peak VM" I had several "red" windows from different VMs sharing a desktop because there was just too-much-stuff)

After that I carefully place windows to different monitors within each desktop (thankfully chromium and firefox seem to remember window relative position, so they tend to spawn in the "correct monitor" most of the time)

edit
P.S.:
I have 6 virtual desktops and am considering buying one more monitor... not sure Qubes+InteIGFX can handle that tho...

[jpouellet]

It's not clear to me what what specifically is the intended benefit of / problem solved by this approach.

• Do you view this as an approach to solving #2646?
• Reducing user attentiveness requirement for differentiating VMs with similar names/colors?
• Somehow mitigating focus-stealing attacks (e.g. by only allowing focus to be stolen by window on same desktop)?
• Solving the problem of identifying which VM a "borderless" window belongs to when multiple of the same color are running? (e.g. nm-applet popup might actually belong to DispVM, because the window has no title in which to display [vm-name] prefix)
• Some other issue(s)?

IMO it would help the discussion to have a common understanding of why people want this feature.

[jpouellet]

It's not clear to me what what specifically is the intended benefit of / problem solved by this approach.

• Do you view this as an approach to solving #2646?
• Reducing user attentiveness requirement for differentiating VMs with similar names/colors?
• Somehow mitigating focus-stealing attacks (e.g. by only allowing focus to be stolen by window on same desktop)?
• Solving the problem of identifying which VM a "borderless" window belongs to when multiple of the same color are running? (e.g. nm-applet popup might actually belong to DispVM, because the window has no title in which to display [vm-name] prefix)
• Some other issue(s)?

IMO it would help the discussion to have a common understanding of why people want this feature.

[tonsimple]

@jpouellet

• is indeed a (partial) solution to #2646 (I am using manual VM-desktop-monitor allocation precisely to cope with many VMs having many GUI windows right now)

• Any solution to managing many VMs would reduce attention-requirement for differentiating VMs (this specific solution would allow to manage many VMs without adding colors/patterns to windows, and would "play nicely" with more colors and/or patterns when they are added)

• And yes, if "vm bound to a specific desktop" (and not allowed to have its windows on other desktops) is prohibited from stealing focus from other desktops, that would mitigate both focus stealing and that other DoS that involves big windows (if VM creates very large windows, but is restricted to messing with a particular desktop and not anything beyond it, the severity of such behavior would be much lower)

So it seems that "most full featured" implementation of this would indeed solve many more problems than just managing VMs, but it would require not only ability to set a "default window spawn desktop" for VM, but also ability to (optionally) prohibit a VM from having its window on any other desktop.

not sure Devilspie2 can do the later, but I pretty much know nothing about how Devilspie2 works.

[tonsimple]

@jpouellet

• is indeed a (partial) solution to #2646 (I am using manual VM-desktop-monitor allocation precisely to cope with many VMs having many GUI windows right now)

• Any solution to managing many VMs would reduce attention-requirement for differentiating VMs (this specific solution would allow to manage many VMs without adding colors/patterns to windows, and would "play nicely" with more colors and/or patterns when they are added)

• And yes, if "vm bound to a specific desktop" (and not allowed to have its windows on other desktops) is prohibited from stealing focus from other desktops, that would mitigate both focus stealing and that other DoS that involves big windows (if VM creates very large windows, but is restricted to messing with a particular desktop and not anything beyond it, the severity of such behavior would be much lower)

So it seems that "most full featured" implementation of this would indeed solve many more problems than just managing VMs, but it would require not only ability to set a "default window spawn desktop" for VM, but also ability to (optionally) prohibit a VM from having its window on any other desktop.

not sure Devilspie2 can do the later, but I pretty much know nothing about how Devilspie2 works.

[tonsimple]

@evadogstar
It appears that one can get devilspie2 "doing what has to be done" in qubes without any patching by using get_class_instance_name() instead of get_window_name()

https://groups.google.com/forum/#!msg/qubes-users/iIQlge9XFLE/sC3v3sAUBAAJ

That appears sufficient for my immediate ergonomic needs.
I will try out devilspie2 and report back.

[tonsimple]

@evadogstar
It appears that one can get devilspie2 "doing what has to be done" in qubes without any patching by using get_class_instance_name() instead of get_window_name()

https://groups.google.com/forum/#!msg/qubes-users/iIQlge9XFLE/sC3v3sAUBAAJ

That appears sufficient for my immediate ergonomic needs.
I will try out devilspie2 and report back.

[evadogstar]

@tonsimple
Yes. Tested and with get_class_instance_name() it works without patching.

[evadogstar]

@tonsimple
Yes. Tested and with get_class_instance_name() it works without patching.