> 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel