Re: GtkList widget and mouse buttons

[Owen Taylor <otaylor redhat com>]

Andreas Tille <tille@physik.uni-halle.de> writes:

> Nevertheless I have a problem with the GtkList widget.
> Using GTK+1.0.? it was possible to select/unselect list items
> with each mouse button.  Now in the GTK+ sources it is explicitely
> checked, that button 1 was pressed and the other two buttons
> didn't cause any effect to a GtkList.  GtkCList seems to have
> the same behaviour and so it isn't an alternative.
> 
> Why it makes sense to use *all* buttons.  I wrote a kind of an
> image viewer:
>    ftp://tower.physik.uni-halle.de/pub/debian-maintain/paul
> It is capable to do operations on single images and on a set of
> selected images.  I presented the images in a GtkList.  A single
> image could be selected with the left mouse button.  To add
> images to the set of selected images one could press the right
> mouse button and to select all images the middle button could
> be used.

Not your point, I know, but what's wrong with standard
SELECTION_EXTENDED behavior where control-click adds addition items to
the selection, and shift-click extends the selection?
Wouldn't it be better to use this than to make your users
learn a different way of selecting multiple items that
only works in your program?

button-3 click is generally used for pop up menus - if
you look at the ChangeLog, you'll see:

Thu Jun 18 23:08:36 1998  Owen Taylor  <otaylor@gtk.org>

	* gtk/gtklist.c (gtk_list_button_press): Only respond
	  to selection with button 1. This allows context-sensitive
	  menus to work correctly.

IIRC, the problem I was trying to deal with there was 
gtk_list_button_press grabs the pointer. If you also
pop up a menu in response to a button press, then
unless you are very careful, because gtk_menu_popup()
also grabs the pointer you'll get into a confused
state.
 
> I solved this by doing 
>   gtk_list_set_selection_mode(filelist, GTK_SELECTION_MULTIPLE);
> and checked in a callback function, which button was pressed to
> cause the specified behaviour.
> 
> So it makes sense to use more than one button to
> get different behaviour for instance.

> The question is: Is there any way to get this behaviour with GTK+1.1.3??
> If not I would strongly recommend to leave out the explicite check
> for the left mouse button to give the programmer more flexibility.

If you connect to "button_press_event" on a listitem, you are
free to do whatever you want in response to the the button
presses, including calling gtk_list_select_child().

> Restricting to only one button does not make sense and if it is
> whished, the programmer can do it easy from his application.

The general goal here is to make things simple for the
programmer trying to do the "average" task. Popping up
context sensitive menus is the most common thing a programmer
will want to do with the other buttons, so I think the
current behavior is a good default.

Lars Hamman, I believe, has some current plans for making the
button actions in GtkCList configurable. A compatible interface
to GtkList should be OK, though IMO, the mouse bindings for a
List (or CList) widget are something that an application should
touch with very great care, since standardization here is
essential from the point of view of the user.

Regards,
                                        Owen