Re: [gtk-list] GTK SELECTION BROWSE question



On Wed, 1 Mar 2000, Nicolas GEORGE wrote:

> Jamie Guinan, dans le message (.gtk.general:1991), a écrit :
> >       items = g_list_append(items, list_item);
> 
> Note: if there are lots of items, you should use prepend and reverse at the
> end.

You're right, thanks.  (Havoc mentions that in his book, too).

> > This deletes the first list item, but the next item does not
> > get selected.  This seems to violate the specified behavior
> > of GTK_SELECTION_BROWSE.
> > 
> > I noticed that the docs say, 
> > 
> >   "Exactly one element is always selected (this can be false
> >    after you have changed the selection mode)."
> > 
> > which is why I explicitly set the first item earlier.
> 
> The testgtk from version 1.2.3 beahaves correctly, and doesn't do extra
> operations, but it uses gtk_list_remove_items. The function
> gtk_container_removes emits the remove signal, that calls the callback
> gtk_list_remove, that then calls gtk_list_remove_items correctly, so I
> don't see the problem. How does testgtk behaves with version 1.2.5?

Its not a problem of removing the items, but leaving one item
highlighted as long as there is at least one item in the list, 
which I believe is the way a list should behave in
GTK_SELECTION_BROWSE mode.  (Please correct me if I'm wrong.)

My Gtk 1.2.5 libs are actually from RedHat 6.1, but I do have CVS 
(v1.3) sources handy.  I tried the following with v1.3 and it 
confirms my problem:

  $./testgtk
  Click "list" button.
    Set "Selection Mode" to "Browse"
    Click "Clear List"       (list is emptied)
    Click "Insert Row"       (first item is selected)
    Click "Insert Row"       (first item still selected)
    Click "Insert Row"       (first item still selected)
    Click "Remove Selection" (first item removed, but no item selected!)
    Click "Remove Selection" (nothing happens, because there is no
                              item selected...)

Looking at gtk_list_remove_items_internal() in gtklist.c, the only 
way it will set the new selection is if "new_focus_child" is set,

  if (new_focus_child && new_focus_child != old_focus_child)
    {
      ...
      if (list->selection_mode == GTK_SELECTION_BROWSE &&
                                         !list->selection)
	{
	  list->last_focus_child = new_focus_child; 
	  gtk_list_select_child (list, new_focus_child);
        }
    }	

Looking back a few lines,

  if (container->focus_child)
    {
      old_focus_child = new_focus_child = container->focus_child;
      if (GTK_WIDGET_HAS_FOCUS (container->focus_child))
	grab_focus = TRUE;
    }
  else
    old_focus_child = new_focus_child = list->last_focus_child;

So either container->focus_child or list->last_focus_child must be
set, but in the situation I described both are NULL. So maybe one 
of these should be set somewhere when list->selection_mode is
GTK_SELECTION_BROWSE?

I tried adding this at the very end of gtklist.c:gtk_list_insert_items(),

  if (list->children && !list->selection &&
      (list->selection_mode == GTK_SELECTION_BROWSE))
    {
      widget = list->children->data;
      gtk_list_select_child (list, widget);
>>>   list->last_focus_child = widget;  <<<<<
    }

and it fixes it for me.  Is this an acceptable patch, Gtk folks?

-Jamie



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