saving/restoring session in kded module

Andriy Rysin arysin at gmail.com
Sat Apr 30 01:56:59 BST 2011


On 04/28/2011 05:08 AM, David Faure wrote:
> On Saturday 16 April 2011, Andriy Rysin wrote:
>> On 03/05/2011 11:32 AM, Andriy Rysin wrote:
>>> There seems to be plenty info on saving/restoring sessions for
>>> applications (i.e. the features in KApplication and KMainWindow
>>> classes) but I'd like to save/restore some information in KDED module
>>> (keyboard layouts to be exact) but only if restore session on login is
>>> set to true (I'd like not to introduce another option in keyboard kcm
>>> but rather reuse system-wide session handing option).
>>>
>>> So far the solution I've found is this:
>>> save/restore session in module dtor/ctor checking if in "ksmserverrc"
>>> the "loginMode" parameter is set to "restoreSavedSession".
>>> This is not very nice as I have to read some other module's config and
>>> compare some string values, though I could not find an exposed native
>>> or DBUS API from ksmserver. Also I noticed that at least two plasma
>>> applets in kde-workspace do exactly that.
>> So I've ended up doing something like the code below, but I was
>> wandering if we should do this at KDEDModule level, i.e.
>> KDEDModule::saveSession()
>> KDEDModule::restoreSession()
>> which would be overridden if necessary and called if session is to be
>> restored so that kded daemons can easily save/restore state, and
>> something like
>> KDEDModule::getSessionStoreDir()
>> to return base directory to store kded module session info so that
>> there's some standard location for this and modules don't have to invent
>> things.
> I like the idea, but we can't add virtual methods to an existing public class
> like KDEDModule, that would be BIC.
>
> This would have to be done with a slot call (invokeMethod).
>
> I don't know if there's a better way than reading ksmserverrc, that's a
> question for Ossi I guess.
>
> But, hmm, to think back about this.... does it really matter if the keyboard
> layout is "the last one the user chose", even when the user said "do not
> restore session on login"? Surely plenty of other configuration options are
> saved by kde applications (e.g. window sizes etc.) and restored the next time
> you run KDE, independently from the "restore session on login" option.
> IMHO that options is about re-opening old windows, not about ignoring any
> saved settings.
Well saving layouts is most useful if the switcher is in 
"per-application" mode (I guess even more when in "per window" but hat 
mode currently can't save layouts as it uses wid for the key which is 
transient). If you restore your session (and thus windows) it makes 
sense to remember which layouts they had. But if you prefer to start 
with a clean sheet (empty session) then saving layouts may be a bit too 
imposing on the user. Although one may argue that in per-application 
mode you always prefer same layout for particular app irregardless 
whether you restore your windows/apps or not.

On the implementation side if we don't honor the "restore session" 
option then new methods in KDEDModule won't add much - you can just save 
in destructor and restore in constructor. getSessionStoreDir() might be 
useful in any case though.

Andriy




More information about the kde-core-devel mailing list