Re: GtkList widget and mouse buttons

[Owen Taylor <otaylor redhat com>]

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

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

Can you reproduce that with testgtk? Here, the list example testgtk
certainly behaves as I describe. (In EXTENDED mode, control-click
selects additional items)

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

Well, if I was designing the UI, I'd add a "select all" button.
If I was getting fancy, I might put that in a right-mouse-button
popup.
 
> > 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.

I think I addressed that below.

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

You can do either one - but if you connect to the List, you'll
probably need to use gtk_get_event_widget() to figure which
item the list occurred in, and thus which item to select.
 
Regards,
                                        Owen