[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: integrating plasma into kdevelop's dashboard
From: Aleix Pol <aleixpol () kde ! org>
Date: 2010-07-27 21:09:35
Message-ID: AANLkTi=byc6YiBg_hFznfibkn6vfGhJodOqUJXkzps0F () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Jul 27, 2010 at 10:51 PM, Aaron J. Seigo <aseigo@kde.org> wrote:
> On July 27, 2010, Aleix Pol wrote:
> > On Tue, Jul 27, 2010 at 10:06 PM, Aaron J. Seigo <aseigo@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
>
>
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Tue, Jul 27, 2010 at 10:51 PM, Aaron J. Seigo \
<span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <div class="im">On July 27, 2010, Aleix Pol wrote:<br>
> On Tue, Jul 27, 2010 at 10:06 PM, Aaron J. Seigo <<a \
href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:<br> > > On July 27, \
2010, Aleix Pol wrote:<br> > > > For the moment I'm implementing it \
passing the project identifier as<br> > > > the first argument when loading \
hte plasmoid. That works just fine for<br> > > > my plugins but I can't \
filter that to the rest of plugins. It would be<br> > ><br>
> > better<br>
> ><br>
> > > if I could receive ::loadApplet myself and choose to call parent's \
if I<br> > > > want to, instead of reimplementing an internal version of the \
call.<br> > ><br>
> > so in internalLoadApplet you wish to do something like:<br>
> ><br>
> > Applet *applet = loadApplet(name, appletId, args);<br>
> > applet->doSomething();<br>
> > return applet;<br>
> ><br>
> > if so, that's easy to implement.<br>
><br>
> no, I meant something like that:<br>
><br>
> Applet* MyPluginLoader::loadApplet(QString name, uint id, QVariantList<br>
> args) {<br>
> Applet *a;<br>
> if(iskdevelopplasmoid(name))<br>
> a=... mystuff<br>
> else {<br>
> args.removeFirst();<br>
> a=PluginLoader::loadApplet(name, id, args);<br>
> }<br>
> return a;<br>
> }<br>
<br>
</div>essentially the same thing, just in a different order. note that you \
don't<br> override loadApplet. that method is not virtual. you reimplement the \
protected<br> internalLoadApplet, which is called from the public (and \
non-virtual)<br> loadApplet.<br>
<br>
while i think there is a better answer to your dilemma (see below) i'll \
adjust<br> PluginLoader so that the above is possible.<br>
<div class="im"><br>
> Here I guess that the problem would be that when restoring I wouldn't \
get<br> > that argument and I would be lost again.<br>
<br>
</div>yes. personally, i'd suggest you provide a built-in dataengine that the<br>
applets can connect to. set the project id in the dataengine, all the applets<br>
will get notified when that happens.<br></blockquote><div>Hmmm... fair enough. \
I'll try that.</div><div><br></div><div>Would it be possible to get what \
Corona/Containment is going to receive the new Applet instance in internalLoadApplet \
reimplementation?</div> <blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br>
> (Just to recall, I have 1-corona/dashboard and 1 dashboard/project and I<br>
> need my applets inside the dashboard to know about the project)<br>
<br>
</div>ah, right. you aren't using the kpart. which means making everything \
work<br> twice. merf.<br></blockquote><div>>.< don't hit me!</div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"> <div class="im"><br>
> > > Custom plasmoid storing and restoring is not yet working. Is that<br>
> > > normal?<br>
> ><br>
> > are they being written out the config file? if so, when being restored,<br>
> > is your internalLoadApplet implementation being called?<br>
><br>
> They're not being written and I don't know why.<br>
<br>
</div>is your code calling Corona::saveLayout() ever?<br></blockquote><div>Ah yes, it \
works for the plasmoids from plasma.</div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;">
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Qt Development Frameworks<br>
</div></div><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br> \
<br></blockquote></div><br>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic