Extender tutorial on techbase

[Sebastian Kügler]

On Tuesday 09 September 2008 16:56:11 Aaron J. Seigo wrote:
> On Tuesday 09 September 2008, Sebastian Kügler wrote:
> > http://reviewboard.vidsolbach.de/r/145/
> > and corresponding thread on this list with subject:
> > "Review Request: PopupApplet iconify patch"
>
> because people will make the wrong decisions. in the submission for 145 it
> says:
>
> " For example kickoff's is always shown when put in the desktop while it
> would be nicer to have it "iconified" as it happens in the panel."
>
> like many things Plasma, this is one of those things people don't "get"
> right away. why would you want a launcher constantly *iconified* on the
> desktop? the entire *point* of having the menu on the desktop is to have a
> launcher visible. 145, essentially, misses the point.
>
> so ... how to do it properly. well, your goal is to :
>
>  * allow the applet to have its own paintInterface.
>  * allow the applet to not expand on the desktop
>
>  i can see a few ways of doing that, but perhaps this is the easiest:
>
> have popupapplet support a null icon being passed into setIcon, which will
> cause it to kill it's own icon. at that point, you are quite free to
> reimplement paintInterface or instantiate your widget.

This doesn't sound very intuitive to me. As to the implementation: How would 
one "kill" the icon?

> the trick would be to only paint / create them in the "correct"
> FormFactors, but that's not rocket science.

What's "them" here?

> this also provides a solution to "allow the applet to not expand": if no
> icon is set, then PopupApplet can simply not switch away from
> Plasma::Dialog.

Uhm, what do you mean by switch away from Plasma::Dialog? Wait ... you mean if 
I nullify the icon and implement paintInterface() then the applet would not 
expand on planar/mediacenter FFs? To me this solution sounds like it has only 
drawbacks. Sure, it makes it harder to do something you don't want. But on the 
plus side, I just don't see any advantage above that, only disadvantages...

> this preserves the "iconified in Vert/Horiz, expanded in Planar" pattern,
> it allows for the clock to use it with no extra effort and it even allows
> people to have an icon on the panel and on the desktop by jumping through a
> bunch of hoops.
>
> so unlike p145, this approach would make the 2 things we want to encourage
> easy and the thing we don't want to encourage tricky but possible without
> it becoming hackish.

I'm fine with anything that makes it unneccessary doing positioning and 
setting up and taking care of the dialog itself in the applets I want to write 
that. I'd like to get rid of that code in the applets I'm currently working 
on. And looking into libplasmaclock makes me dizzy.

I'm quite unsure on the implementation details, but that might be me being 
dense after today's hacking over here ...
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20080909/30e21b28/attachment.sig