Extender tutorial on techbase

[Aaron J. Seigo]

On Tuesday 09 September 2008, Marco Martin wrote:
> On Tuesday 09 September 2008, 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:
>
> i'm still thinking could make sense to give applet a function like
> showExtender() that makes a popup (and forcing to use extenders instead of
> something else),

that's the point of PopupApplet; otherwise i would have just added to Applet's 
API directly.

> i see like two different things, like an applet that Has a
> popup vs popupapplet that is an applet that Is a popup

which is provided for in my proposed patch.

has a popup: set a null icon
is a popup: set a valid icon

> and the popup function in applet could look differently in the panel or in
> the desktop, the clock for instance could look something like this

this is a different topic, i think.

i'd also caution against overdesigning things so that the difference between 
extenders, popups and applets all become so tangled up and nuanced that it 
becomes very confusing for people trying to use the API casually.

remember that we see this API every day, so keeping our innocence about it is 
hard. but our #1 audience is people who see the API once or twice in a year.

right now we have:

* Extenders: allows for additional items that are associated with applets

* PopupApplet: provides the code for an on-click popup associated with an 
applet, eliminating code duplication. may be used with Extenders.

* Applet: works with Extenders, is the parent class of PopupApplet, provides 
just the basics.

that's not too difficult to communicate and pretty straightforward.

it might be useful to step back and consider the discussions around 
DataEngines a year ago: they source->dictionary hierarchy was too limiting, 
they "needed" to be read/write, etc, etc.. there were all sorts of 
complications suggested, none of which have actually been needed in practice. 
in fact, the simplicity is *THE primary feature*.

as a team, we end up in this same sort of discussion for nearly every bit of 
the API that we spend too much time with. why? we become comfortable with the 
API, master it, then try and do new tricks with it that lead us to want to 
make the API even more complex ... and we forget about simplicity. we forget 
to challenge ourselves to accomplish our goal with the simpler API. we forget 
that we're not here primarily to obsess over the framework, but to make things 
with it.

a good exercise that i've found to try and avoid this pitfall is to imagine in 
my mind a new coder who pops up on the irc channel. i then imagine myself 
explaining what i'm working on to them. this is often an eye openner.

another good exercise is not allowing myself new API; i pretend that it is 
Simply Not An Option. even if this means i have to go away for a day or two 
and think about it all frustrated, usually i eventually come back with a much 
better way to do it. sometimes it doesn't need new API at all. sometimes we 
end up with a new class altogether (that's how Plasma::Service came about).

just some thoughts to help improve our shared design process =)

-- 
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 Trolltech

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