Fwd: Pager and Desktop Layout

[Jason Kasper <vr movingparts net>]

Keeping this on-list...

--

-[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-

-[ KDE PIM Developer         //  http://www.kde.org  ]-

-[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-

Begin forwarded message:

From: Ryan Beasley <ryan beasley+foss gmail com>
Date: August 2, 2011 5:18:52 AM EDT
To: Martin Gräßlin <mgraesslin kde org>
Cc: Jason Kasper <vr movingparts net>
Subject: Re: Re: Pager and Desktop Layout

On Tue, Aug 2, 2011 at 1:53 AM, Martin Gräßlin <mgraesslin kde org> wrote:

On Tuesday 02 August 2011 01:16:15 you wrote:

May I ask why exactly you need to adjust the desktop layout? Maybe it is just the wrong

approach? In our opinion the desktop layout belongs to the desktop shell and should therefore

only be changed by the desktop shell and not by any third party process.

Even without this change on our side the behavior was more or less undefined as the

settings would not have been persisted and most likely the pager plasmoids would not have

updated their view.

Sure. This is for VMware's (not to be confused with Ubuntu's) Unity
feature. You could imagine a user doing the same with NX or perhaps
anything else offering a rootless X experience.

Imagine you have two desktop sessions, one on your local computer and
the other in a virtual machine or on a remote host. Rather than
interact with remote applications entirely within a single window
(such as within a VM console embedded inside VMware Workstation,
VirtualBox, or what have you, or an independent X server root window
on Mac OS X), you're allowed to pull the individual applications'
remote windows out and interact with them as you would anything else.
This means interleaving VM/remote windows with your local windows'
stacking order, grouping them as you'd like on different desktops,
etc.

To do this, however, it's best (well, more or less mandatory) if the
local and remote geometry, desktop layout, etc. match. For us, we
configure the guest VM's desktop layout to match that of the
virtualization host. So if running on a Kubuntu host w/ 4 desktops in
a 2x2 config, upon entering Unity we reconfigure the guest VM to match
that same 2x2 layout. (We revert to whatever the original layout was
at exit, too.)

The atom is still used and in fact our KCM does nothing else then changing the atom.

Nevertheless I highly recommend to not change this atom from a 3rd party application as that

changes the state of the desktop shell and can lead to user problems especially as the

changes of 3rd party applications are not persisted.

Hm, okay. Points taken. I'll admit that we've done a suboptimal job
w.r.t. guest VM code integrating correctly, and I'm trying to do a
better job with that now.

I apologize if I'm going off-topic re: this list's charter, but what's
the alternative? Having remote control of the desktop layout is a
must-have from our POV. Just as KDE's session manager supports both
D-Bus and XSM, if we assume there are programmatic KCM hooks (*really
waving my hands here*), would it really be that much trouble to have
writes to the _NET_DESKTOP_LAYOUT atom be handled internally the same
way as someone going through KCM?

Thanks much.

 - Ryan