integrating plasma into kdevelop's dashboard

Aleix Pol aleixpol at kde.org
Tue Jul 27 23:09:35 CEST 2010


On Tue, Jul 27, 2010 at 10:51 PM, Aaron J. Seigo <aseigo at kde.org> wrote:

> On July 27, 2010, Aleix Pol wrote:
> > On Tue, Jul 27, 2010 at 10:06 PM, Aaron J. Seigo <aseigo at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100727/d82da554/attachment.htm 


More information about the Plasma-devel mailing list