Re: GtkList widget and mouse buttons

[Andreas Tille <tille physik uni-halle de>]

On 2 Dec 1998, Owen Taylor wrote:

> 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?
I consider the following behaviour when using SELECTION_EXTENDED:
click: like SELECTION_SINGLE
shift-click: select from focus to clicked
control-click: if you click onto an unselected item like SELECTION_SINGLE
               if you click onto a selected item deselect this item

I don't see any default way to add a single item to other items like in
SELECTION_MULTIPLE.
I don't see any default way to easily select all items.  I'd consider it
to be boring to set focus to first or last item and press shift-click
to select all instead of pressing a single button like I did former.

> 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.
I read this but I don't know if there isn't any other way arount
this.  Why don't support a mask for those programmers that don't want
to use such menus.  The default may be as it is, but the possibility
gives much more flexibility and is easy to implement thought.
 
> 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.
Thanks, that is in fact a reason my poor mind can cope with and so
I have to find a way around, if nobody is willing to implement
the mask-solution.

> 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().
Do I understand right that I have to connect each single
listitem instead of the list widget?  May be that is the reason
for my unsuccessful trials.  Before I asked the people in
the list I tried to implement it this way but failed.
May be I give it one more try.
 
> 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.
Not to offend you but for my poor mind the behaviour I described
above is a little bit strange and I wouldn't consider it to
be as a good default.  May be I did something wrong (I didn't found
any detailed documentation) or I havn't the right feeling for
GUI programming (it is my first GUI).
 
> 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.
OK, I could live with a CList, too.  I chosed a GtkList because
I have only one column and I wanted to keep the thing as simple
as possible.  By the way:  Is there any reason why GtkFileSelection
uses CLists as single column lists?

Thanks for the answer

    Andreas.