Extender tutorial on techbase

[Rob Scheepmaker]

On Tuesday 09 September 2008 09:14:51 Sebastian Kügler wrote:
> On Tuesday 09 September 2008 02:26:51 Aaron J. Seigo wrote:
> > On Monday 08 September 2008, Marco Martin wrote:
> > > in popupapplet adding the possibility ti replace the icon with a
> > > generic QGraphicsWidget

I agree, if we make PopupApplet slightly more advanced, libplasmaclock can use 
it, amongst others, and we can cut back massively in duplicate code. Because, 
as Marco suggested, extenders will usually be used inside popups. What about 
adding a virtual function QGW *collapsedWidget() which default implementation 
returns a icon, so default behavior doesn't change, but developers can also 
show custom widgets as needed by the clock and battery applet.

> > this probably makes sense. the question would be how to make a nice API
> > for it.
> >
> > there will *still* be cases where this fails and some code will need to
> > be written, but it's one more case covered at least.
>
> The case I've run into is that I'd like to add a popup to a normal applet
> (in this case the battery). So I'd still want all the magic in
> paintInterface() to work, and then just add a dialog. That's *mostly* what
> popupapplet does, but aq couple of things make it unusable for that case:
> No option to always have it behave like in the panel (i.e. on planar /
> mediacenter FFs, it always expands. There has been a patch for it, but it
> wasn't merged, not sure why, but I would use it. 

agreed, what about a protected setNeverExpand or something like that (i suck 
at creating good names for functions, but you'll get the idea.

> Right now, I end up with
> setting up the dialog and positioning by hand, something I can 'mostly'
> copy over from either popupapplet, or libplasmaclock (both are slightly
> different
>
> :/).
>
> So can we have something like the normal applet combined with popupdialog?
> The following methods should be there:
>
> - paintInterface() for 'normal applet painting' (not just a graphicswidget)
> - setHasPopup() and createPopup(Plasma::Dialog dialog) (enables a dialog,
> much like createConfigurationInterface() in Applet)

I doubt createPopup is needed, we already have widget() and graphicsWidget() 
in which you can decide what your dialog should contain.

> - widget() and graphicsWidget() (to fill the popup with widgets or
>   plasma::widgets
>
> What I would not like to do:
>
> - take care of on-demand create of the dialog
> - take care of positioning the dialog
>
> Another problem is that libplasmaclock has a really "interesting"
> implementation of the extenders. I first took that as an example (in the
> mid_control applet, but it prove buggy, then I read the tutorial, went
> "wtf, libplasmaclock is doing something fairly different"). I didn't get
> the code to work well ... look at mid_control applet if you want to see the
> details.

Yeah, I focussed on PopupApplet for extenders until now. Take a look at 
kuiserver (playground) for an example of a real world applet that uses 
extenders and isn't very buggy. I was already under the impression that 
libplasmaclock should be using PopupApplet some day.

> For the things I'm working on (control panel area with dialogs popping up),
> the needs are all fairly similar, and sound like something that should be
> absolutely easy to do. Yet it's not. Modulo my stupidity.
>
> That said, I think the API of the extenders (or what I read in the
> tutorial) is OK, now we need to rule out the bugs :>

Yes, I fixed a lot of bugs there last week, and I'm now at the point where I'm 
very interested in bug reports since there aren't any major and obvious bugs 
left... well in libplasmaclock there are but once that uses popupapplet, that 
should be solved.

Regards,
Rob Scheepmaker