Hi Jonathan, I have some comments to make, although I don't know GtkTreeView much so bear with me. :-) > 2. Feature requests: > > Here's a list of possible behaviors that people have requested over > time. It's a little muddled -- hopefully further descriptions below > will clear it out > > * Activation: activate on single click, double click, or not at all I don't know what "activation" means in the GtkTreeView world. Does it just mean selecting a row, moving the keyboard focus to a row, clicking on a row, or all these things at once? (I looked at the documentation, and I couldn't find a clear explanation.) In any case, I don't understand why you would want this to be customizable? > * Expansion: Expand on selection, expand on double click, or expand > only when the arrow is clicked. I think this is also a bad idea, since it introduces more inconsistencies between applications. Expansion should only happen when the arrow is clicked; that's a standard GUI behavior that should not be overridden on a per-app basis. > * Drag: Drag selected rows. I am not sure what this means exactly, but I think a drag operation should *always* drag all the selected rows -- that's just the way a tree/list widget is expected to work. > Drag only certain columns. What is this about? I can't think of an example of when you would want to use this. > current interface is model based, and possibly needs fixing. Campd > made a compelling argument for doing this view based. This one I fully agree with. > * Drop: Have a distinction between dropping on the name and the blank > area, and on the actual row. This sounds like a must have... > * Selection: Current behavior, rubberband selection, click-and-drag > selection (like the clist used to have in BROWSE). This also sounds like an added inconsistency that is not worth the time. Selection should work predictably across all the apps. If you want click-drag selection to work, then it should *maybe* happen only automagically when drag and drop is not enabled for the widget and the widget is in multi-select mode. Surely it should not be left to the app to decide. > * editing: Currently, the behavior for editing confuses users. I'm not > 100% sure how we should fix it, but we should at least see how other > toolkits do it. AFAIK, in Cocoa if you mark a cell as "editable" double-click on the cell edits it, or at least that's the default behavior. In those apps where double-clicks opens the item (like the Finder), slow double click triggers editing. (I don't know what the current GtkTreeView is.) > So what's the question here? It's largely one of API. I can see us > adding these features as time permits over the next couple GTK+ > iterations, without any large plan. This is dangerous, as the features > interact in unexpected way. For example, as described above, I might > add a call like: > > gtk_tree_view_set_activations_style (GtkTreeView *tree_view, GtkTreeViewActivationStyle style); > > which would let me set double_click to activate the row. How that > interacts with setting double_click to expand a row is unclear. This sounds to me like a sign that neither (mis)feature should be implemented. :-) > A possible alternate API is to focus on the events themselves. Ie, have > an API like: > > gtk_tree_view_set_double_click_action (GtkTreeView *tree_view, GtkTreeViewDoubleClickAction action); > > This is nice in that it deals with possible conflicts of settings by > tying only one behavior per user action. It however, is messy, as not > all actions are well defined. I'm not really happy with the thought of > adding a call like: > > gtk_tree_view_set_click_and_drag_when_on_certain_column_contents_action(); > > To handle the drag-only-items case that nautilus wants. I agree they both sound messy. > 4. A possible third way > > As an alternative, we could lump all the behaviors into one > uber-mode and set that. Possible behavior sets I see are: This would sound slightly better, but I still don't see a compelling case for customizing the behavior of the widget besides the basic allow-single-selection/allow-multiple-selection choice (which, I assume, is already there?). -- Ettore
Attachment:
signature.asc
Description: This is a digitally signed message part