KDE/kdebase/workspace/plasma/applets/tasks (silent)

[Sebastian Sauer]

okeli, this time I'll try to keep the mail small, promised :)

On Tuesday 05 February 2008, Aaron J. Seigo wrote:
> > > it's not an easy ballancing act for me, to be honest, and i'm looking
> > > for feedback and input. on saturday we'll be discussing whether to keep
> > > review-board or not, for instance. is it helping or hindering
> > > development? is it useful or just a pain? etc...
> >
> > oh, it can be a quit useful thing. E.g. myself would land his work to
> > turn the "configure desktop" dialog into a kcm there (nah, far away from
> > beeing ready or usuable yet) since it just touches lot of code and review
> > would be more then welcome there.
>
> this is something we should discuss before you start coding on it as there
> are probably some non-obvious issues to take into consideration. in
> particular, the DefaultDesktop can be replaced by any other Containment.
> which means that the eventual "desktop background" kcm needs to handle
> containments and get configs from there. i've discussed this before with
> some of the people working on the desktop wallpaper stuff, but if someone
> is going to work on the Next Step of this, i probably need to sit down and
> write out some of the design issues that need to be taken into
> consideration.

y, I am aware that this can't be done like in KDE3 just with a "for desktop: 
1..n" combo. Anyway, it was mainly an example and did not went to anything 
usuable and I wan't have time for it anyway nor do I believe, that it's 
really that important yet. But it was a good sample of something that just 
needs review and more discussions anyway some time in the future.

> > It's just the case that a "each commit needs to go through a webbased
> > board and you have to wait some time till somebody says ok" solution just
> > is overhead++ imho.
>
> that's never been the goal. things in your own engines/applets keep going
> the way they always have; if you can get peer review elsewhere, great; if
> the fix is obvious or it's a trivial add, go for it.
>
> this is all about non-trivial changes to core elements.

then it may depend on what trivial means. I would go so far to say, that all 
the commits I did so far where trivial and I stopped at the only one that was 
imho non-trivial cause there where just different ways how to do it and I was 
just totaly unsure what would be the best; the "Add Containment 
contextActions() to widget conext menu". Through I guess it was wise to add 
that oneline-hack and quit a lot of text for what it may needed + a todo and 
a fixme note.

Following quotes deal imho all with the same issue;

> and even then, there have been times when people have worked on a given
> thing straight into svn (the wallpapers being an example there), though
> often working with someone else as well to bounch ideas off of.

> > Guess I still don't got that point about "design principles". Is it those
> > GUI-dialog? Well, that was really only 5% of the work (in terms of time
> > that was needed till it was working).
>
> the GUI dialog is one thing. the actual settings (tiny, small ..) are
> another as it doesn't translate well to a non-dialog approach,
> introduces "interesting" behaviour like when you set it to custom but the
> same size as one of the presets, etc ...

> > works somehow is in. Somebody will extend it later anyway just like I
> > extend the work others did.
>
> it isn't that easy. let's say that this configuration style is put into 4.1
> and people start saving their config files with it. now we have to support
> it from the point out. and if that happens to make approaching our goals
> with plasma (which are not, btw, "recreate kicker's feature set") then
> what? yeah, we're screwed. that's why these things are slightly important.
>
> i understand you just want to set the size of your panel. i have no issue
> with that. but if scratching that itch and throwing the result into svn
> means jeopardizing the long term goals here, what do you think?

> it's not about perfection in every commit, it's about trying to make sure
> that plasma has a future in spite of everyone's good intentions.
>
> as a simple example, how often do you think about plasma's use:
>
> a) in other apps
> b) in a media center presentation
> c) on devices without mice
> d) on small devices like the eee pc
>
> or how plasma will be used by different user segments?

imho Plasma has all this in place already. I am looking here at one specialy 
use-case for one special goal while keeping in mind with each commit those 
long-time goals you communicated about so far.

my goal here is; 4.1
the use case; KDE3 like desktop (nope, not the kicker-ueberpower but just 
those parts that are resulting in the usual "plasma-mess" and "it's unusable" 
feedback and users like me not being happy with the current limitations aka 
oldies that just like to have a "traditional desktop").

I guess that's pretty clear taken into account how much I pushed for the 
traditional menu (and later a bit extended kickoff as well) and now for some 
basic panel configuration. I am also very aware, that this is only one single 
aspect of the whole goal.

But I also guess that this isn't a question of "if you go for this goal then 
you lose the other goals" as long as it's done in a way that doesn't suck up 
the other use-cases / goals aka libplasma.

Anyway, I guess we are yet in such a state (the location of the panel was the 
only remaining big thing myself was missing to replace KDE3) and I guess it 
was an important thing to address this use-case for 4.1.

btw, none of my commits did touch libplasma but only plugins where the changes 
done at the panel-plugin are probably those most "offensive" cause of the GUI 
+ "size" configitem. Well, I hope that kickoff+traditionell menu applet 
doesn't count here taken into account that I don't work since yesterday on 
both of them.

> these are the sorts of things i sort of *have* to think about on a fairly
> regular basis. yeah, makes my life a little more annoying ;) and it would
> be awesome if we can all find a way to make it work out so that while i'm
> also worrying about these things that you probably don't need to really
> care about that your efforts don't result in negative side effects.

ok, what about limiting it to features while bugfixes can still go in without 
review?