Start of extender API draft

[Kevin Ottens]

Le Saturday 31 May 2008, Rob Scheepmaker a écrit :
> On Friday 30 May 2008 18:38:30 Kevin Ottens wrote:
> Let's first consider the 2 points you make:
> > 1) If the "detachable widgets" are a new class, I've this feeling that in
> > the end they'll duplicate quite a lot of Applet features (need for layout
> > management, config, formfactor, etc.).
>
> Ok, detachable widget will do some own config, but I think the duplication
> will end there. You have to understand that detachable widgets are never
> meant to exist 'stand alone'. They always are part of a 'host applet'. So
> when you detach such a widget from an extender, a new extender applet is
> created right where the widget is dropped, and the detachable widget is
> added to it. When dropped on an existing applet, it is just added to that
> applet. And in case the widget needs some applet api (dataEngine for
> example), the public api of the host applet can be accessed without any
> trouble. But in most cases dataEngine is the only applet specific api
> function that needs to be accessed, so why not avoid the overhead of using
> full applets for detachables?

OK, from a user pov I somehow expected to have them exist standalone though.

> > 2) It's probably easier to design more complex applets making use of
> > extenders with a compound approach. That particularly strucked me looking
> > at your examples. Most of the applets are views on some piece of data,
> > and in the example you gave they're always of the same type (a set of
> > jobs, a set of timezones, etc.).
>
> (which doesn't mean we don't want to support creating different types of
> course. We don't want people's creativity limited by technical limitations
> if we can avoid it)
>
> > Let's take the "jobs" example. The easiest path is
> > to design an applet able to display one job, make sure it's ok for the
> > layout, form factor and such. Once I'm happy with that, having a
> > "kuiserver applet" is basically creating a compound applet able to create
> > "jobs" sub-applets. That also sounds like a nice upgrade path for people
> > designing their complex applets: make simple pieces and glue them
> > together.
>
> I'm personally of the opinion that using QGraphicsWidgets is actually a
> simpler approach and provides an easier migration path in most cases.

For the record Applets are QGW, so you're just stripping down the features at 
hand. And the debate really is: are the extra features of Applet worth it for 
detachables to implement the extender idea? (because they have the same form 
factor and load/reload constraints than proper applets I tend to answer yes 
there).

> Let me explain why:
> 1) We already have quite some nice qgw's in libplasma, and most likely,
> that collection will become larger over time. Stuff like signalplotters,
> icons, webcontent, meters, pushbuttons, labels. For a lot of detachables,
> creating one of those widgets, or maybe a couple which are combined using
> layouts, is all there is to it. A lot of applets already use these widgets
> and migration to using extenders for these applets will be very painless,
> as opposed to having to create a new applet just for using detachables.

Right.

> 2) Other applets which already display 'lists' of items, and which are
> obvious candidates for extenderification, already use custom implemented
> QGW's, look for example at the notify applet. Again, migration will be
> easier here.

I'm not sure which "notify" applet you're referring to. The only one I'm 
thinking of which has a list like that is the device notifier, and it'll be a 
pain to migrate whatever solution you choose. :-)

> 3) Most detachables won't need the overhead of being full 
> applet and can use the hostApplet for certain applet api that they do need.

That's where I'm doubtful because of the reload needs.

> 5) Probably a moot point, but I'm philosophically against using applets for
> thing that actually don't have any meaning on it's own, which would be the
> case for quite some detachables. ;)

Well, that's really a matter of personal perception, if that can be separated 
from its applet, be there even if the said applet is not around anymore, be 
moved... that looks a whole lot like an applet. :-)

> I hope this makes some design decisions clear. Again, please feel free to
> convince me that I'm entirely wrong here, these kinds of discussion can
> only benefit all.

You're not entirely wrong if that helps, but just I'm wondering if you're 
going to reinvent quite a few applet facilities for the detachable widgets.

> > >     {
> > >         public:
> > >             static QGraphicsWidget *createDetachableWidget(Extender
> > > *hostApplet, const KConfigGroup &config);
> >
> > Why is this one public? And even static? Is that useful outside of the
> > extender implementation?
> > I doubt it, it probably should be non static (a clue for that is that you
> > pass the hostApplet as parameter, so why not calling on the hostApplet),
> > and for sure it should be protected since it's only the business of the
> > applet subclass to decide when to create detachable widgets.
>
> Your right, as dimsuz also pointed out, static won't work very well. The
> thing I'm trying to avoid though, is the need to have an instance of the
> source applet to create detachables. Yes, when you detach stuff from an
> applet, remove that source applet, and restart plasma, the detachable
> should still be there. I'm not really sure what's the best way to implement
> this. Separate Factory class maybe?

Well... if they'd be applet of their own... ;-)
Otherwise yes, that'd mean a separate factory which would know which applet to 
reload. Probably something which could be kept private. Try to keep only the 
single factory method in the public API.

> > >             void addWidget(QGraphicsWidget *widget, const KConfigGroup
> > > &config, const QPointF &position = QPointF());
> >
> > I *guess* it's to add to an extender a widget which was previously
> > created using the static factory method above...
>
> yes, although when creating widgets, you don't necessarily need to use that
> factory method. That factory method is for re-instantiating the detachables
> after a plasma restart.

In such a case it could probably be made private. I'm missing the whole 
picture right now to be sure how, but that's a good indication of something 
which shouldn't be public.

> You're of course free to use it in your applet as 
> well.
>
> > I also suspect it's to pass around
> > widgets between extenders? If I'm right, then it probably makes sense to
> > make it public.
>
> Yes, spot on. :)

After thinking again about it, maybe not... I don't see a case where you want 
to programmatically pass these around. On user interaction that's different, 
but then it could probably be hidden.

> > >             void setAssociatedExtender(Extender *applet);
> >
> > I've no idea what this one is for... I have an extender, why would I want
> > to associate it with another one?
>
> One very common usecase (as explained in the doxygen ;) ) of extenders is:
> you have an applet. When on the desktop it shows a list of detachables.
> When in the panel it doesn't have enough room for that and it hides all its
> detachables in an other extender which appears when you click the applet
> (of hover or whatever). With this method you can set this extender so
> detachables move around automagically. Still people should be able to
> disable this behavior: what if an applet uses multiple extenders for
> example.

I still don't get why a separate extender would be needed for that...

> > >             QString sourceAppletName();
> > >             int sourceAppletId();
> > >             ExtenderApplet *sourceApplet();
> >
> > I would only expect the sourceApplet() method here. All the other ones
> > can be queried through the sourceApplet itself if I'm not mistaken.
>
> Problem here being that, as I explained earlier this mail we don't always
> have an instance of the source applet since detachables should be able to
> live on independently. Still we need to know what that applet was to be
> able to recreate the detachables it spawned.

Well, you also said they never live stand alone (which was your main argument 
to not make them Applets)... So, can they live standalone and indeed you 
don't have those information at hand (and then that means sourceApplet() 
could return 0... from an API stand-point I'd read that as a detachable with 
no source), or they can live standalone and you position against Applet might 
need to be reevaluated.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080602/6139fd41/attachment.pgp