[Panel-devel] KDE/kdebase/workspace/plasma/applets/kickoff

Sebastian Sauer mail at dipe.org
Sun Dec 16 21:13:05 CET 2007


Aaron J. Seigo wrote:
> honestly, i don't like that we have a configuration dialog with one item
> in it. ugh. it also introduces a string that's really not needed for 4.0.
> plasma isn't exactly string frozen, but it might be nice not to abuse that
> privelege toooo much? =)

so, remove th ui-options and leave it up for hand-editing the kconfig-files 
per hand? I guess things like to disable the "switch on hover" may really 
useful for those that do not or can not go with the default. But I see your 
point re to much ui-options (through there are disabled / not visible to the 
user if "lock widgets" is enabled ;)

probably such options should really have no ui but just like gnome we could 
provide access to the advanced options another way. Sounds more like a common 
question for me :-/
 
> btw, the use of d->switchOnHoverCheckBox->setCheckState with the ternary
> could just us setChecked(true). easier, though it's already done so it
> hardly matters now =)

ah, right :)
 
> why does LauncherApplet have a dptr? it's not a publicly exported class
> and never will be, unless i'm missing some larger scheme here?

it just keeps the header clean.
 
> also, is there some reason that kickoff diverges more and more and more
> from the plasma coding style? i'd *really* like to see applets and engines
> in workspace/plasma/ make at least an effort to conform to the plasma
> coding style if only because, well, it would be nicer to have a consistent
> code base.

I followed the coding style I found within the kickoff-codebase.
 
> anyways, it's in there now and while i'm not particularly comfortable with
> this commit, there's no real point in reverting it now. in future perhaps
> we can continue the tradition of peer reviewing such additions on
> panel-devel, however.

hmmm, okeli. I'll wait with future commits past 4.0


More information about the Panel-devel mailing list