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+f...@gmail.com> > Date: August 2, 2011 5:18:52 AM EDT > To: Martin Gräßlin <mgraess...@kde.org> > Cc: Jason Kasper <v...@movingparts.net> > Subject: Re: Re: Pager and Desktop Layout > > On Tue, Aug 2, 2011 at 1:53 AM, Martin Gräßlin <mgraess...@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
_______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
