[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