Faster grouping -- less clicks

Maciej Pilichowski bluedzins at wp.pl
Sat Jul 11 13:19:48 CEST 2009


On Friday 10 July 2009 22:36:37 Matthew Woehlke wrote:

> > But I am thinking about one feature more -- the checkbox
> > [ ] do not close it after drop
> > in the hollow pane. Just thinking aloud! :-)
> >
> > By default, unchecked, no change there. But if user would check
> > it, it would mean, that with each drop, the pane does not
> > disappear, and sequential adding is possible.
>
> Sure. I assume there is a "go away" button in hollow, also?

You mean "cancel"? Yes.

> And I 
> guess it remembers last setting?

Oh, yes.

For the rest -- it is my mistake, sorry for that. I was thinking about 
incremental adding via hollow pane, and I didn't say it explicitly. 
SORRY!

> (*Or to make D&D easier; IOW, what the wiki currently says. We
> could also have it be used in conjunction with a deco button "add
> this to container with hollow app", but I still don't see where
> ctrl-LMB comes into play here. Hmm, I wonder if that would make
> Diego happy? I'd be much more happy with that than somehow colored
> "current container".)

We could also mix this a bit, to add flexibility.

For example:
* you could create container and select two apps to make the container
* you could point out one app, and add another app to it

so it is like
A + B 
A += B

The effect is exactly the same. But it let user choose the preferred 
way.

The ctrl+LMB is also effect of mixing -- since it is used when 
creating container from scratch, it could be used to add window 
instead of d&d in incremental mode.

> Create container mode as previously/currently defined already takes
> N clicks plus two actions ("action" might be click or keystroke) to
> make container from N windows. (Actually only plus one action if
> activated from button on deco.)

Yes, you are right, I went to far with my thoughts -- I was thinking 
about reducing clicks when hollow pane is used -- so when you create 
container by incrementally adding apps, not by selecting bunch of 
them.

One wiki will be operational I will clarify the summary about this 
point.

Cheers,


More information about the Kde-usability-devel mailing list