Review Request: Corona::exportLayout

[Chani Armitage]

> On 2010-09-26 20:22:05, Aaron Seigo wrote:
> > trunk/KDE/kdelibs/plasma/corona.cpp, line 340
> > <http://svn.reviewboard.kde.org/r/5451/diff/1/?file=38404#file38404line340>
> >
> >     this should probably take a KConfigGroup, since KConfigGroup can refer to the top level item, e.g. the whole config file, using the magic QString() name for the group.
> >     
> >     unfortunately, Corona::importLayout() requires a KConfigBase which would make this assymetrical. iirc that bit of the API was written before i was aware of that KConfigGroup trick (which was actually undocumented until i found out about it :).
> >     
> >     perhaps we should add an importLayout that takes a KConfigGroup, mark the importLayout which takes a KConfigBase as deprecaton and have it call the new one.
> >     
> >     then we have a nice api with symmetry?
> 
> Chani Armitage wrote:
>     so... void Corona::exportLayout(KConfigGroup *config, QList<Containment*> containments)
>     and void Corona::importLayout(KConfigGroup *config)
> 
> Aaron Seigo wrote:
>     KConfigGroup &, but otherwise, yes...

I thought it was bad form to use & without const...?


> On 2010-09-26 20:22:05, Aaron Seigo wrote:
> > trunk/KDE/kdelibs/plasma/corona.cpp, lines 359-362
> > <http://svn.reviewboard.kde.org/r/5451/diff/1/?file=38404#file38404line359>
> >
> >     what does calling updateConstraints even do in this case? looking at the code in Applet, this just schedules a call to flushPendingConstraintsEvents with a timer. is it actually needed at all?
> 
> Chani Armitage wrote:
>     iirc, it propogates the change to the applets... hmm, which wouldn't work if they were systemimmutable.
>     so I ought to do it myself instead.
> 
> Aaron Seigo wrote:
>     i don't think updateConstraints does anything like that since here's the code of that method:
>     
>         // Don't start up a timer if we're just starting up
>         // flushPendingConstraints will be called by Corona
>         if (started && !constraintsTimer.isActive() && !(c & Plasma::StartupCompletedConstraint)) {
>             constraintsTimer.start(0, q);
>         }
>     
>         if (c & Plasma::StartupCompletedConstraint) {
>             started = true;
>         }
>     
>         pendingConstraints |= c;
>     
>     which means nothing happens until the event loop is hit again. setting the immutability makes sense, just not the call to updateConstraints.

it's in ContainmentPrivate::containmentConstraintsEvent()

but anyways, moot point now :) I'll have it iterate through the applets and access their dptr to force it to mutable.


- Chani


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5451/#review7824
-----------------------------------------------------------


On 2010-09-25 16:51:30, Chani Armitage wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5451/
> -----------------------------------------------------------
> 
> (Updated 2010-09-25 16:51:30)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> this adds exportLayout to corona, which saves a group of containments to a config file and deletes them from the main config.
> 
> Activity::close() becomes a lot shorter by calling it, like this: m_corona->exportLayout(external, m_containments.values());
> 
> I feel a bit out of it today though, so tell me if I've missed anything obvious...
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdelibs/plasma/corona.cpp 1177115 
>   trunk/KDE/kdelibs/plasma/corona.h 1177115 
> 
> Diff: http://svn.reviewboard.kde.org/r/5451/diff
> 
> 
> Testing
> -------
> 
> closing an activity while locked is perfectly safe now :)
> 
> 
> Thanks,
> 
> Chani
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100927/4c52bd9f/attachment.htm