On Tue, Jul 27, 2010 at 10:51 PM, Aaron J. Seigo <ase...@kde.org> wrote:
> On July 27, 2010, Aleix Pol wrote:
> > On Tue, Jul 27, 2010 at 10:06 PM, Aaron J. Seigo <ase...@kde.org> wrote:
> > > On July 27, 2010, Aleix Pol wrote:
> > > > For the moment I'm implementing it passing the project identifier as
> > > > the first argument when loading hte plasmoid. That works just fine
> for
> > > > my plugins but I can't filter that to the rest of plugins. It would
> be
> > >
> > > better
> > >
> > > > if I could receive ::loadApplet myself and choose to call parent's if
> I
> > > > want to, instead of reimplementing an internal version of the call.
> > >
> > > so in internalLoadApplet you wish to do something like:
> > >
> > > Applet *applet = loadApplet(name, appletId, args);
> > > applet->doSomething();
> > > return applet;
> > >
> > > if so, that's easy to implement.
> >
> > no, I meant something like that:
> >
> > Applet* MyPluginLoader::loadApplet(QString name, uint id, QVariantList
> > args) {
> > Applet *a;
> > if(iskdevelopplasmoid(name))
> > a=... mystuff
> > else {
> > args.removeFirst();
> > a=PluginLoader::loadApplet(name, id, args);
> > }
> > return a;
> > }
>
> essentially the same thing, just in a different order. note that you don't
> override loadApplet. that method is not virtual. you reimplement the
> protected
> internalLoadApplet, which is called from the public (and non-virtual)
> loadApplet.
>
> while i think there is a better answer to your dilemma (see below) i'll
> adjust
> PluginLoader so that the above is possible.
>
> > Here I guess that the problem would be that when restoring I wouldn't get
> > that argument and I would be lost again.
>
> yes. personally, i'd suggest you provide a built-in dataengine that the
> applets can connect to. set the project id in the dataengine, all the
> applets
> will get notified when that happens.
>
Hmmm... fair enough. I'll try that.
Would it be possible to get what Corona/Containment is going to receive the
new Applet instance in internalLoadApplet reimplementation?
>
> > (Just to recall, I have 1-corona/dashboard and 1 dashboard/project and I
> > need my applets inside the dashboard to know about the project)
>
> ah, right. you aren't using the kpart. which means making everything work
> twice. merf.
>
>.< don't hit me!
>
> > > > Custom plasmoid storing and restoring is not yet working. Is that
> > > > normal?
> > >
> > > are they being written out the config file? if so, when being restored,
> > > is your internalLoadApplet implementation being called?
> >
> > They're not being written and I don't know why.
>
> is your code calling Corona::saveLayout() ever?
>
Ah yes, it works for the plasmoids from plasma.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
