Re: [Usability] rubberbanding in gtktreeview



On Wed, 2003-11-12 at 15:41, Carlos Morgado wrote:
> 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. 

No offense intended, but -- what are you talking about?

> You do know ctrl is now used to toogle between copy/move now  
> right ?

and? how does that affect RB? If i say 'Nautilus' does it ring a bell?

> 
> > > 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.

???

ever used nautilus?

> 
> > >
> > > 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.

So learning one rule and apply that rule everywhere isn't efficient
right?

> 
> > 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.

Right, which is another thumbs up for RB since that functionality is
also preserved in a RB environment. For those who use this kind of
function, i never discovered that until recently. I've been using RB for
ages.

> 
> > 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.

It never does. What it does is to make a *new* selection each time which
discards a previous one. you *can't* remove item2-13 from a item1-item17
selection at once. *That* would be deselecting.

> 
> > *can't* handle discontinous blocks. It doesn't *pre-select/hilight* for
> 
> Yes it can (with ctrl).

Definitely *not* in gtk+/gnome. Shift+ctrl however does work in other
GUIs, but it's painfully complicated for an average user. click on one
row, shift-click on another row to make a block selection, press ctrl to
add another single row then press both shift+ctrl to add another block. 
How wonderful.

> 
> > 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 ?

Try to drag a rectangle in nautilus icon view. Icons touched by RB
rectangle get preselected, highlited. Button-release confirms the
selection.

> 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 ?

Both drag&drop and RB. you grab the object, you do d'n'd. you drag in
empty space you do RB.

*No* keybinding please.

> 
> > 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.

What are you talking about? Have you *ever* used RB? With RB you can
still have your own selection model in place and of course the most
important thing which is drag'n'drop. It's an essential part of the RB
selection model. 

> (actually, I just noted ctrl+shift selection doesn't work very well on gtk+2  
> lists, oh well)

It doesn't work at all. See above.

> 
> > >
> > > 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 ?

No you can only select a row *currently*.

> 
> 
> > > 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.

I'm talking about gtktrees, so it's either list or tree. What kind of
apps have you tried? Don't say outlook ;)
I recommend that you play around with the RB model a bit more on your
win box.

Marek
 




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