tktable-tile-dev

[Tile-dev] Tree API -- selection and focus

[Joe E. <jen...@fl...>]

For consistency with other parts of Tk, it would make sense
to just clone the listbox widget selection command.

On the other hand, that's not a very good match for the tree
widget: the 'set' and 'clear' subcommands operate on ranges,
and tree items don't have a natural linear ordering.
(There are several reasonable linear orders for items, but
it's not always obvious what's in the range "between"
two items, especially if $first and $last don't have the
same parent).  Besides that, I've always found the listbox
selection command somewhat clunky.

I propose the following instead:

    $tree selection --
	Returns the list of selected items.  The list is sorted
	according to the preorder traversal order (that is,
	it doesn't matter in which order items were added
	to the selection).

    $tree selection add $items --
    	Add $items to the selection.

    $tree selection remove $items --
    	Remove $items from the selection.

    $tree selection set $items --
    	$items becomes the new selection.

    $tree selection toggle $items --
    	Toggle the selected state of each item in $items.

And possibly:

    $tree selection clear --
    	Deselect everything.
	This is the same as '$tree selection set {}'.

A <<TreeviewSelect>> event is generated in all cases
(except for [$treeview selection]), even if the selection
hasn't actually changed (e.g., adding an item that was
already selected still generates the event).


Notable differences from [$listbox selection]:

    + There's no separate [$tree curselection] command;
      [$tree selection] with no additional arguments does the same thing.

    + Unlike [$listbox selection set $first $last], [$tree selection set $l]
      *does* affect the selection state of items not mentioned in $l.
      [$listbox selection set] is closer to [$tree selection add].

    + There's no selection anchor.

    + [$tree selection toggle] is included so the common operation
      of toggling the selection state of a single item can be
      done atomically.


There is also a distinguished "focus" item; this is where the
location cursor is drawn, and is the target of most keyboard
operations.  [$treeview focus] returns the current focus item,
and [$treeview focus $item] sets it.

The listbox widget uses an "activate" command and an "active"
index for this concept.  I'm trying to be more consistent with
terminology in the Tile package, and "active" means "the thing
under the mouse pointer" in other contexts; hence "focus" instead
of "active".

The widget ought to support both "single" and "multiple"
selection modes ("browse" and "extended" seem like unnecessarily
subtle distinctions).  I'd rather not add a -selectmode option
if it can be avoided; another way to support this is with distinct
sets of bindtags (which in turn can be selected by setting
the -class option).  Will try both and see how it works out...


--Joe English

  jen...@fl...

Re: [Tile-dev] Tree API -- selection and focus

[Bryan O. <br...@bi...>]

Joe English wrote:
> A <<TreeviewSelect>> event is generated in all cases
> (except for [$treeview selection]), even if the selection
> hasn't actually changed (e.g., adding an item that was
> already selected still generates the event).
> 

What's the advantage to generating the event when the selection command 
is called, versus only generating it when the selection changes? I'm not 
sure I see it, though I'm betting you've recently thought about this 
more than I have. All things being equal, I think I'd rather have it 
only be generated when the selection actually changes.

Re: [Tile-dev] Tree API -- selection and focus

[Joe E. <jen...@fl...>]

Bryan Oakley wrote:
> Joe English wrote:
> > A <<TreeviewSelect>> event is generated in all cases
> > (except for [$treeview selection]), even if the selection
> > hasn't actually changed (e.g., adding an item that was
> > already selected still generates the event).
>
> What's the advantage to generating the event when the selection command
> is called, versus only generating it when the selection changes? I'm not
> sure I see it, though I'm betting you've recently thought about this
> more than I have. All things being equal, I think I'd rather have it
> only be generated when the selection actually changes.

What I was thinking is, [$tree selection] is usually called
because of some user action (clicking on an item, navigating
with the arrow keys, etc.), and the <<TreeviewSelect>> binding
is more of a response to the user gesture than it is to the
selection changing.

Also, the listbox widget works this way: with -selectmode single,
clicking the currently-selected item generates a <<ListboxSelect>>
event, even though the selection doesn't change.  (Conversely,
if the application calls [$l selection set] it *doesn't* generate
an event).

What you suggest makes sense though -- generate the event when
(and only when) the selection changes.  I'll implement it that
way initially, we can change it later if warranted.

The widget will probably also need a -command or -browsecommand
callback option; applications can use that to respond to
user gestures.  (The class bindings are getting fairly complicated
and [$tree identify] remains a hairball; the way it stands now
it won't be as easy for applications to define widget instance
bindings as it is with the Listbox, so the Treeview will
need to provide an easy way to do this.)



--Joe English

  jen...@fl...