> On March 16, 2012, 12:49 p.m., Ivan Čukić wrote:
> >
> 
> makis marimpis wrote:
>     Hm, i did that in order to restore the desktop ids from a previous run of 
> kamd (let's say, in case of log out).
> 
> Ivan Čukić wrote:
>     You misunderstood, I don't mind saving it in the config file, I don't 
> understand the need to keep all those in memory.
>     
>     For example, Bob has 20 activities, usually uses only 3 of them. Why 
> would you want to keep the rest of the VD IDs in memory?
>     
>     Just read the VD ID when necessary.
>     
>     As you can see, we are not keeping anything that is saved to a config 
> file in memory apart from the list of activities. The names, icons etc. are 
> read from the config when needed.

Now i see your point.
I have implemented the same patch using only KConfigGroup but because of the 
"scheduleConfigSync" there is a case where the sync cannot keep up with the 
change of the activities - leading to a weird behavior (the changes are not yet 
made volatile).
That could be solved by calling "configSync" explicitly but that could affect 
the performace? (no idea).

To sum up: i think it is faster and less error-prone to store in memory and 
sync whenever sync is scheduled to, than to read/write whenever an activity is 
changed.


- makis


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104261/#review11467
-----------------------------------------------------------


On March 16, 2012, 11:55 a.m., makis marimpis wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104261/
> -----------------------------------------------------------
> 
> (Updated March 16, 2012, 11:55 a.m.)
> 
> 
> Review request for KDE Runtime and Plasma.
> 
> 
> Description
> -------
> 
> Patches kactivitymanagerd to store (and restore back) the working current 
> directory when switching activities.
> 
> The activity-changing-behavior is as follows:
> 1.  Say you have two (or more activities) A and B.
> 2.  You are working on activity A on Desktop 4.
> 3.  You switch to activity B (and by default to Desktop 4).
> 4.  Change to Desktop 1.
> 5.  Go back to activity A and (by default) to Desktop 1, while it should move 
> you to Desktop 4 (this is where my patch kicks in).
> 
> I hope it makes sense :-)
> 
> 
> This addresses bugs 241864 and 265015.
>     http://bugs.kde.org/show_bug.cgi?id=241864
>     http://bugs.kde.org/show_bug.cgi?id=265015
> 
> 
> Diffs
> -----
> 
>   service/ActivityManager.cpp 7af2049 
>   service/ActivityManager_p.h d054eb7 
> 
> Diff: http://git.reviewboard.kde.org/r/104261/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> makis marimpis
> 
>

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to