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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
