Re: [Usability] rubberbanding in gtktreeview



On 2003.11.12 15:01, Marek Peteraj wrote:


> most common is action is multiple selections but is a nuissance for
> applications where drag'n'drop of single items is the norm.

The RB proposal doesn't remove the drag'n'drop functionality at all.


It either removes the drag'n'drop functionality or creates even more keybindings. You do know ctrl is now used to toogle between copy/move now right ?


> He then goes on to
> use keybindings he previously claimed are to complex for normal users.

Where? What i proposed is to *unify* the keybindings for the selection,
proposing ctrl for adding *both* single or multiple selections to
extisting selections *everywhere*.


See above.
Also, your ctrl method is a pain for big selections.

>
> The new scheme would also break expected behaviours of existing
applications
> and disrupt usage paterns for users.

No. The scheme would unify the selection behaviour throughout the entire
desktop which is one of the most important things in a well designed UI.

No. The most important thing in a well designed UI is being efficient. Otherwise it's useless.

If a user learns RB for icons, he doesn't have to learn another type of
hidden keybinding style selection for gtktrees. I'm using gnome for
3,5yrs and i didn't know about shift until recently. Besides what it


The shift method works on all GUIs/Toolkits I've ever seen.

does is simply to make a continuous block of selected rows in both
directions on the Y axis, that's up or down. It *never* deselects. It

Yes, it does.

*can't* handle discontinous blocks. It doesn't *pre-select/hilight* for

Yes it can (with ctrl).

selection. And it's accessible only through a keybinding. I think a

I don't understand the pre-select, how does that work ? mouse-over ?

keybinding is unacceptable for an easy to use environment. But note that

On 2003.11.11 18:35, Marek Peteraj wrote:
It's easy with RB and follows the unifying UI rule i was proposing, For
single selections ctrl-cliking adds one object/row to a selection of
one/more objects/rows. For multiple selections ctrl-dragging a rectangle
adds a bunch of objects/rows. Same rule - use ctrl to add selection
whether it's single or multiple, you select only objects in a gtktree
just like icons are objects.


What is it then ? No drag'n'drop ? Or keybinding only ?

ctrl has been adopted by every desktop available for adding selections.

And that's what gtktree uses now.

So it's kind of an exception and a keybinding seems not avoidable in
this case.


What would change would be *removing* the ability to make big selections *quickly* and replacing it with something we already have or removing drag'n'drop. (actually, I just noted ctrl+shift selection doesn't work very well on gtk+2 lists, oh well)

>
> I finally claim the Box concept doesn't make sense for unidimentional
> objects.

As i stated in my previous emails, i don't think they are
one-dimensional. You've got rows which can be considered as 1D if you
don't count their height which is always the same size so i understand
how this theory came to be, but you're not selecting horizontally nor
are the rows placed one after another horizontally. They're placed
vertically, and if you have more than one column, the playground clearly
becomes two-dimensional.


How so ? Can you select 2 columns of 2 rows in a GtkTree ?


> Drawing a rectangle around a line segment isn't a familiar concept
> anywhere.

How about every other OS(win, macosx, kde)?


MSWindows (which is the only one I have here at hand to experiment with) does *not* allow box selection on lists or trees. You're probably confusing trees with tables. That would explain a lot.


--
Carlos Morgado - http://chbm.net/  gpgkey: 0x1FC57F0A
FP: 0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]