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: Martin Gräßlin <mgraess...@kde.org> > Date: August 2, 2011 4:53:18 AM EDT > To: Ryan Beasley <ryan.beasley+f...@gmail.com> > Cc: Jason Kasper <v...@movingparts.net> > Subject: Re: Re: Pager and Desktop Layout > > On Tuesday 02 August 2011 01:16:15 you wrote: >>> >>> In fact the pager plasmoid is stopping to use the manager selection and not >>> setting the >>> desktop layout any more. The desktop layout is initially set by kwin and >>> can be updated >>> through the multiple desktops kcm. If other processes change the desktop >>> layout KWin > will >>> adjust the layout though it may be that the setting change is lost when >>> restarting KWin. >>> >>> In general I would say that the behavior if changes to desktop layout are >>> not done through > the >>> expected way is undefined. >>> >>> >> Hm. This poses a problem for me. One of the products I work on depends on >> being able to reconfigure the desktop layout in a desktop environment/window >> manager-agnostic manner. The idea is that the properties of the destination >> desktop session are to (temporarily) be in sync with a source desktop >> session. In my particular case, I'm not concerned with persisting the >> settings across sessions, so not having them saved as part of the KDE >> settings store isn't a problem. > 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. >> >> If controlling the atom via _NET_DESKTOP_LAYOUT *does* go away, I'd very >> much love to see a generic mechanism (e.g. D-Bus?) replace it, else I have >> to add another implementation that knows how to speak KCM (I guess?). > 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. >> >> Handling to support and drive GNOME/KDE/kwin4/Metacity/Compiz/etc. all >> separately is a major pain in the rear. wm-spec bits, at least when they're >> supported correctly, makes my job much easier. :) > Yes I know that wm-spec is not really helpful - one reason why we decided to > abandon one > of the more idiotic parts ;-) > > Cheers > Martin >> >> - Ryan
_______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
