On Tuesday 02 August 2011 02:18:52 you wrote: > 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. Yeah I understand. In that case I think it would be best to not have a desktop shell in the guest system, but to have the guest windows really connecting to the host X Server. And I think it should not matter so much for the desktop shell in the guest system how the desktop layout looks like in the outer world. But for that use case the KWin internal changes should not matter. It will be as "broken" as before. > > 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? I think it would be not optimal if 3rd party started to modify our underlying KConfig files (that's what the KCM does) as we of course do not provide any guarantee on how these settings are stored and might change in any release (while writing this sentence I just realized that we need an update script to sync the settings from the previous config file to the kwinrc). Cheers Martin
Attachment:
signature.asc
Description: This is a digitally signed message part.