Hi, Apologies for the late reply, have been very busy lately. Comments inline.
On Fri, Apr 04, 2008 at 08:07:42PM +0100, Carlos Pereira wrote: > ************************************************************ > 1) In GtkTreeview with GtkListStore, show always the first item as default, > when selection is SINGLE or BROWSE > > Sometimes it makes sense to have a default, sometimes it doesn't. GTK+ has to have a default here and as always defaults will not work for all cases. This is not a default that we can just change at this stage, since multiple applications are relying on this. However if wished there are enough ways to put your own behavior in place here. The main point is that for key navigation you really want to put the cursor *somewhere* to start navigating. Then the first item of the list is a logical choice. That the cursor row gets selected as soon as the tree view receives focus is another "default". Again this is behavior you can change yourself if wished. Do distinguish "cursor row" from "selected row" here, this is something that people often forget. > In GTK_SELECTION_SINGLE there is always a default, for a GtkListStore, > and this default is the first item on the list. This is wrong! If I > think that a default > should be set, I should be able to easily do it myself, not GTK for me! > > Interestingly enough, when GtkTreeStore is used, then no default is set... > even for GTK_SELECTION_BROWSE! even when the tree nodes have no > child, so they behave exactly as list nodes (so the SAME lists produced > with TreeStore and ListStore behave differently...) The tree view does not behave differently in this regard and I cannot observe any differences between its handling of normal and LIST_ONLY models. > 2) Click to select, Ctr Click to unselect > > In computer interfaces, everytime we have two-state choices (up-down, 0-1, > yes-no, true-false), the solution should be: click to change the state. > So if you are in > state 0, clicking takes you to state 1, clicking again takes you to > state 0, and so on... I do not think it is valid to compare changing selection in tree and icon views with the buttons on WM decorations. You can argue that select/unselect is a two-state operation, but I have yet to see an interface where tree and icon view selection actually behaves as a two-state operation. > ********************************************************* > 3) In both GTK_SELECTION_SINGLE and GTK_SELECTION_BROWSE modes, > with a GtkListStore, this code gets the correct selection, when clicking > on a row, > if you are NOT pressing Ctrl or Shift keys: > > However, if you are pressing Ctrl or Shift, when selecting a different > item, this code returns the PREVIOUS item, not the current one. You are connecting to the cursor-changed signal, which has nothing to do with the selection state. When the selection is changed, the "changed" signal on the GtkTreeSelection is emitted. If you connect to that signal instead, you will see that your test case works as expected. regards, -kris. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
