[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Declarative UI Integration, reprise
From:       Alan Alpert <alanalpert () optusnet ! com ! au>
Date:       2009-09-26 16:06:44
Message-ID: 200909270206.44915.alanalpert () optusnet ! com ! au
[Download RAW message or body]

On Sat, 26 Sep 2009 22:01:33 Marco Martin wrote:
> On Saturday 26 September 2009, Alan Alpert wrote:
> > On Thu, 24 Sep 2009 22:07:31 Marco Martin wrote:
> > > On Thursday 24 September 2009, Alan Alpert wrote:
> > > > On Thu, 24 Sep 2009 20:38:16 ext Marco Martin wrote:
> > > > > On Thursday 24 September 2009, Alan Alpert wrote:
> > > > > ...
> > > > That's actually a really good idea, since if you want just a QML item
> > > > you probably won't be wanting to write a C++ applet for it. I
> > > > probably should have noticed this since I didn't even use
> > > > KineticApplet when I wrote my C++ applet example (it had to subclass
> > > > WeatherPopupApplet). The plasma items do
> > >
> > > what you would do i this case is just subclass WeatherPopupApplet and
> > > add just
> > >
> > > > need to be given an Applet*, but I suppose that can be passed around.
> > > > I agree that this approach is more powerful.
> > >
> > > oh, i see, plasmoiditem needs to dump properties in the config file...
> > > finiding the parent applet on init is easy, but the config file would
> > > get corrupted if the parent applet changes (that usually doesn't
> > > happen) hmm perhaps it should init to the parent applet configgroup and
> > > have a setconfigGroup() so it could be used also outside Applets?
> >
> > I don't quite understand what you mean here. I'm not aware of any
> > situation where you would move parts of an applet between applets (change
> > the parent
> 
> no there isn't and probably never will be a situation where a widget is
> reparented between applets, is just an assumption that wasn't used before
> 
> > applet). And I also don't understand what you mean by 'used also outside
> > Applets', since the PlasmoidItem is meant to expose Plasma::Applet
> > functionality in QML. Could you give an example?
> 
> well, it doesn't exactly expose the applet functionality, it just gives
>  access to the config and the theme, and would be come even more obvious if
>  it will be used from the plasmaqmlview class, (where an applet could for
>  instance having more than one of them) hmm maybe it should even be called
>  not Plasmoid in qml, but something like plasmaqmlitem?
> 

It is supposed to be the link between the QML and the Plasma::Applet, but with 
the possibility of multiple ones integrating into a C++ applet that's no 
longer the whole Plasmoid. What aspects of the applet functionality is it 
missing though? It needs to provide all the functionality of a Plasma::Applet 
that a plasmoid designer would need.

This actually reminds me that the main reason the one Plasmoid item design was 
done was so that the Declarative UI could integrate nicely into the plasma 
QGraphicsScene. Since Qt Declarative has solved that problem itself since i 
wrote the Plasmoid item, I can conceive now removing the Plasmoid item 
entirely. The question remains whether that would be a good idea. I'd think 
it's still desirable to have a root Plasmoid item for purely QML Plasmoids.

I think I'll spend more time thinking about it rather than leaping at an 
implementation this time. If the Plasmoid item stays as is though, you are 
right that it should be renamed.

-- 
Alan Alpert
_______________________________________________
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]