Re: [Tile-dev] Strawman Tree widget API

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

Andreas Kupries wrote:
> > [...]  I *hope* that it's simple enough
> > to figure out how to use the widget from the manpage alone --
> > I've omitted the EXAMPLES section on purpose to test if that's
> > actually the case :-)
>
> So far I had no trouble.

Good :-)

> I would change 'remove' to 'detach', the inverse opration is 'attach'.
> If 'remove' is kept as name the inverse should be 'add'.

The more I think about it, I'm not even sure 'remove' is needed.

[ The original motivation for this was: I was toying with the
  idea of having [$tree children $item] take an optional
  third parameter, which would specify a new list of children
  for $item.  That raised the question: what happens to the
  _old_ children if not all of them are listed in the new list?
  Answer: Easy, they're still referenced in the hash table,
  just not part of the tree anymore.  Next thought: since that's
  possible, why not add a 'remove' command?

  Anyway, I'll probably implement the three-argument form
  [$tree children $item $newchildren], but don't know if
  remove/detach is worth keeping. ]


> Horizontal scrolling is definitely something which should be done. ... Might
> be restricted to the values though, and not the hierarchy column at the
> left.

Should this scroll by pixels or by whole columns?
Whole columns is (IMO) probably more useful, but scrolling
by pixels seems to be more conventional.

> > I'm not too sure about the names 'open' and 'close'.
> 	Alt. names: 'show' and 'hide'.

Thought about this, but since it's the item's _children_
that are shown/hidden, not the item itself, open/close
(or expand/collapse, suggested by Brian, which I think I
like better) is more appropriate.


> Should I open the discussion about separation of widget and data ?
>
> 	I.e. that the tree data is a separate object the tree widget/view
> 	connects to ? Multiple widgets for one tree, different visual
> 	state, for the same data ? Ability to use special tree data
> 	objects which have no actual tree in memory ? (= virtual trees)

I hadn't considered this, but am open to suggestions.
The Tk way of doing this would be a linked -variable;
but for the tree widget the contents of the variable
would have to be a fairly complicated structure.


--Joe English

  jen...@fl...