tktable-tile-dev Mailing List for TkTable / Tile / Vu (Page 30)

> Joe English wrote:
> 
> 
> > 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.
> 
> Couldn't it just be an array (or dict)?
> 
> array set data {

Remember Brian Griffin's mail as well, he had some ideas regarding
this too. Even based on actual experience.

I quote ...

> ... would also like to see an incremental or dynamic interface that
> allows for support of larger datasets.  We have an interface on our
> tree that is comprised of three configure options: -querycommand,
> -querysizecmd, -queryblocksize.  The -querycommand is called
> whenever a node is expanded (opened), and is passed the node id (""
> for root).  The command will return a list of items which are the
> children for that node.  Each element of the list is a list of
> triples, one triple for each column.  The triple is comprised of
> {<label> <tags> <image>}.  The label and image should be obvious.
> The tags element is a list of flags, the primary ones being
> "branch", or "leaf".
 
> In the simple case, all the children for a node are returned when
> requested.  To handle large datasets, the -querysizecmd and
> -queryblocksize are used.  Before calling -querycommand, the
> -querysizecmd is called to calculate the number of children for the
> node.  Then the -querycommand is called with two additional
> parameters, a start index and a count (count comes from
> -queryblocksize).  The callback will only return "count" items
> starting at the start index.  The widget determines what range is
> needed based on the scroll offset and only makes enough calls to get
> the data needed to satisfy the display.  Also, the command callbacks
> support % substitution for node (%n), start (%s), and count (%c).
 
> I find this interface easier to use then the traditional "$w insert
> ..."  interface, especially when the data is dynamic.  A simple
> trigger can be used to cause the widget to re-acquire the data from
> the callbacks.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

--- Joe English <jen...@fl...> wrote:

> 
> Brett Schwarz  wrote:
> 
> > [Joe English]
> > > I'm not sure how useful user-supplied node IDs
> are [...]
> > 
> > One thing I use explicit node names for is so that
> I
> > can identify the node during callbacks (i.e. when
> > selected). Think of it as "client data" in the
> node
> > name. I'm not sure if this is the right way to do
> this
> > or not, but I find it comes in handy.
> 
> I often do the same thing myself -- often times the
> data
> displayed in the tree comes from some other source
> that has
> its own node identifiers; that's why I chose the
> BWidget
> syntax initially, so the tree widget identifiers
> match
> the source data identifiers.
> 
> On the other hand, just about as often the source
> data *doesn't*
> have any notion of a node identifier, so there's an
> extra burden 
> on the programmer to manufacture one.  This could
> just be a matter
> of using "#auto" and letting the Tree widget
> generate one, 
> but still...
> 
> > Of course, one
> > could just keep a reference to the node id
> (generated
> > from treeview) and client data in a separate
> > structure, but I kind of like keeping it together.
> 
> That's what you have to do when using the Canvas
> widget too.
> 
> On balance, I think the 2-argument form is
> preferable to
> the 3-argument one.  It's easier to use in the
> common case,
> simplifies the internals, reduces the number of
> error paths, 
> and saves a bit of memory.  I'm strongly leaning
> towards that 
> right now.
> 

ok, how about another option (I know, I know, not
another one). But maybe a clientdata option, so you
can leave clientdata for that node. Really haven't
thought it through, but I am still thinking that there
should at least be an option to associate data to that
node. Could be:

    -clientdata
or maybe more specifically
    -nodename

The latter might be preferred in the case of searhing
for certain nodes and/or testing for certain nodes.
(see below).

> 
> > One other thing that I think is missing, is a way
> to
> > find out if a node exists. In BWidgets, it would
> be:
> > 
> > $widget exists <nodename>
> 
> Would this still be useful if node IDs weren't
> user-supplied?
>
I guess not, but that's another reason to have
nodenames ;) 

Ok, here's one of the reasons I use $pathname exists
nodename. If I am dynamically generating the Tree
structure, I want to find out if the node already
exists (i.e. there might be duplicates), and maybe I
don't want to show duplicates.

Also, if I am dynamically generating nodes, and there
is a hierarchy, then I want to test to see if the
parent node exists first, before adding the child
node. If it exists, then add the child, if not, the
add the parent first:

if {[$path exists parentnode]} {
    $path insert end parentnode childnode ... [*]
} else {
    $path insert end root parentnode ...
    $path insert end parentnode childnode ...
}

Again, I could keep all this info in a separate
structure, but it just seems right to keep them
together...

    --brett


[*] or of course, it could be:
$path insert end parentnode -nodename childnode ...

Joe English wrote:


> 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.

Couldn't it just be an array (or dict)?

array set data {
     0 "/"
     0,0 "usr"
     0,0,0 "local"
     0,0,0,0 "bin"
     0,0,0,0,1 "tclkit"
     0,0,0,0,2 "tclsh"
     0,0,0,0,3 "wish"
     0,0,0,1 "lib"
     0,1 "etc"
     0,1,0 "hosts"
     0,1,1 "passwd"
     ...
}

One could fetch all the children of, say, /usr/local/bin via [array 
names data 0,0,0,0,*], and so on.

I'll admit I haven't really thought this through, but it seems like a 
reasonable approach on the surface.

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...

Brett Schwarz  wrote:

> [Joe English]
> > I'm not sure how useful user-supplied node IDs are [...]
> 
> One thing I use explicit node names for is so that I
> can identify the node during callbacks (i.e. when
> selected). Think of it as "client data" in the node
> name. I'm not sure if this is the right way to do this
> or not, but I find it comes in handy.

I often do the same thing myself -- often times the data
displayed in the tree comes from some other source that has
its own node identifiers; that's why I chose the BWidget
syntax initially, so the tree widget identifiers match
the source data identifiers.

On the other hand, just about as often the source data *doesn't*
have any notion of a node identifier, so there's an extra burden 
on the programmer to manufacture one.  This could just be a matter
of using "#auto" and letting the Tree widget generate one, 
but still...

> Of course, one
> could just keep a reference to the node id (generated
> from treeview) and client data in a separate
> structure, but I kind of like keeping it together.

That's what you have to do when using the Canvas widget too.

On balance, I think the 2-argument form is preferable to
the 3-argument one.  It's easier to use in the common case,
simplifies the internals, reduces the number of error paths, 
and saves a bit of memory.  I'm strongly leaning towards that 
right now.


> One other thing that I think is missing, is a way to
> find out if a node exists. In BWidgets, it would be:
> 
> $widget exists <nodename>

Would this still be useful if node IDs weren't user-supplied?


--Joe English

  jen...@fl...

Sorry about the previous post.  Blame M$ Exchange server...

-Brian

Joe English wrote:

>
> As a starting point for discussion, I've posted
> a strawmanpage here:
>
>     <URL: http://tktable.sourceforge.net/tile/doc/treeview.html >
>
> The documented interface is still incomplete, but I think
> it's a pretty good start.  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 :-)
>
> Stuff that's missing:
>
> + Need to keep track of an "active" or "focussed" item;
> + Support for selections;
> + Drag and drop support, or (more likely) a foundation upon which
>   drag and drop support could be built.
> + A way to specify column headings, column widgths, and other stuff
>

Headings need to be buttons with -commands, and support label/image 
combinations

>
> + Might want to be able to turn different components on and off:
>   column headings, open/close indicators, tree "connecting lines",
>   maybe even the tree labels to support "pure" multicolumn listboxes.
>
>
> Some things I like about this design:
>
> Separate -columns and -displaycolumns options make it easy
> to hide or reorder columns without having to change all the
> item -values.
>

Yes!

> It works as a plain tree (leave -columns empty and don't
> supply -values for any items), and -- almost -- as a plain
> multicolumn listbox (create all items as children of the root
> and leave out -text and -image.)
>
> Some things I'm not too keen on:
>
>     $tree insert $index $parent $itemid ? ... options ... ?
>

I different approach may be to have two methods, one that adds an item 
after the index as a sibling, and another that adds an item as a child 
of the index.  Which raises a question: are indexes relative to the 
parent node, or absolute?  If a parent node is collapsed, what happens 
to the subsequent indexes?  Maybe what's needed is a path like index 
scheme (e.g. "1.2.2.1.7")

> I copied this straight from the BWidget Tree, just to have a
> starting point.  I'm not sure how useful user-supplied node
> IDs are; it may be better to just use widget-generated integers
> like the canvas does.  This would reduce the number of required
> arguments from 3 to 2; and since then it's incompatible with
> BWidget anyway we can swap the order of the first two arguments
> and make it:
>
>         $tree insert $parent $index ?... options ... ?
>
> which seems more natural to me.
>

Without a UID, how do you find something in the tree?  The UID is not 
necessarily a hierarchical list of labels.  For example, a Windows 
explorer like display, where the file extensions are hidden.  The label 
for two files can be identical, but the file names themselves are different.

> I don't like the overloaded nature of the "-columns" argument --
> either an integer representing the number of columns or a list
> of symbolic column names.  But I *really* like the ability to
> have named columns, and if we had separate -numbercolumns
> and -columnnames options it'd be more work for users and for
> the widget to ensure they were always consistent.
>

Following the "everything-is-a-string" paradigm, I would just say that 
all columns are named; period.  This also gives you a default header label.

> Specifying "-displaycolumns {}" (the default) means that all
> columns are shown, in order.  There is no way to say "do not
> display any columns".
>
> The -height option should really specify the desired number of
> visible items, not the height in pixels.  I'm not sure what
> units '-width' ought to take.
>

I've never liked "item" based sizing.  It leads to funky window resizing 
behavior.

> The return value of [$tree identify $x $y] is a hairball.
>
> I'm not too sure about the names 'open' and 'close'.
>

How about "expand" and "collapse".

> I'm also not too sure about the number of widget commands;
> maybe some of these should be merged into a subensemble.
>
>
> Other stuff to think about:
>
> Item states: there are a few item states that the tree indicator
> element should be aware of, so it can select an appropriate display
> based on whether the node is open or closed, and whether or not
> it's a leaf element.  None of the currently-defined TTK_STATE_*
> flags really match those concepts well.  "selected" might serve
> for open/closed, except that we also want to support listbox-style
> selections.  I'm using the USER1 and USER2 state flags internally
> right now for open and nonleaf, respectively; but there really
> ought to be a mechanism for assigning meaningful names.
>
>
> Comments?
>

I would also like to see an incremental or dynamic interface that allows 
for support of larger datasets.  We have an interface on our tree that 
is comprised of three configure options:  -querycommand, -querysizecmd, 
-queryblocksize.  The -querycommand is called whenever a node is 
expanded (opened), and is passed the node id ("" for root).  The command 
will return a list of items which are the children for that node.  Each 
element of the list is a list of triples, one triple for each column.  
The triple is comprised of {<label> <tags> <image>}.  The label and 
image should be obvious.  The tags element is a list of flags, the 
primary ones being "branch", or "leaf".

In the simple case, all the children for a node are returned when 
requested.  To handle large datasets, the -querysizecmd and 
-queryblocksize are used.  Before calling -querycommand, the 
-querysizecmd is called to calculate the number of children for the 
node.  Then the -querycommand is called with two additional parameters, 
a start index and a count (count comes from -queryblocksize).  The 
callback will only return "count" items starting at the start index.  
The widget determines what range is needed based on the scroll offset 
and only makes enough calls to get the data needed to satisfy the 
display.  Also, the command callbacks support % substitution for node 
(%n), start (%s), and count (%c).

I find this interface easier to use then the traditional "$w insert ..." 
interface, especially when the data is dynamic.  A simple trigger can be 
used to cause the widget to re-acquire the data from the callbacks.

-Brian

>
> --Joe English
>
>   jen...@fl...
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>

-- 
-------------------------------------------------------------
--                 Model Technology Inc.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-------------------------------------------------------------
-- Technical support ............ mailto:su...@mo... --
-- Sales and marketing info ....... mailto:sa...@mo... --
-- Licensing .................... mailto:li...@mo... --
-- Home Page ........................ http://www.model.com --
-- AIM ........................................ bgriffin42 --
-------------------------------------------------------------

Joe English wrote: 


As a starting point for discussion, I've posted 
a strawmanpage here: 

    <URL: http://tktable.sourceforge.net/tile/doc/treeview.html <http://tktable.sourceforge.net/tile/doc/treeview.html>  > 

The documented interface is still incomplete, but I think 
it's a pretty good start.  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 :-) 

Stuff that's missing: 

+ Need to keep track of an "active" or "focussed" item; 
+ Support for selections; 
+ Drag and drop support, or (more likely) a foundation upon which 
  drag and drop support could be built. 
+ A way to specify column headings, column widgths, and other stuff


Headings need to be buttons with -commands, and support label/image combinations




+ Might want to be able to turn different components on and off: 
  column headings, open/close indicators, tree "connecting lines", 
  maybe even the tree labels to support "pure" multicolumn listboxes. 


Some things I like about this design: 

Separate -columns and -displaycolumns options make it easy 
to hide or reorder columns without having to change all the 
item -values.


Yes!





It works as a plain tree (leave -columns empty and don't 
supply -values for any items), and -- almost -- as a plain 
multicolumn listbox (create all items as children of the root 
and leave out -text and -image.) 

Some things I'm not too keen on: 

    $tree insert $index $parent $itemid ? ... options ... ?


I different approach may be to have two methods, one that adds an item after the index as a sibling, and another that adds an item as a child of the index.  Which raises a question: are indexes relative to the parent node, or absolute?  If a parent node is collapsed, what happens to the subsequent indexes?  Maybe what's needed is a path like index scheme (e.g. "1.2.2.1.7")





I copied this straight from the BWidget Tree, just to have a 
starting point.  I'm not sure how useful user-supplied node 
IDs are; it may be better to just use widget-generated integers 
like the canvas does.  This would reduce the number of required 
arguments from 3 to 2; and since then it's incompatible with 
BWidget anyway we can swap the order of the first two arguments 
and make it: 

        $tree insert $parent $index ?... options ... ? 

which seems more natural to me.


Without a UID, how do you find something in the tree?  The UID is not necessarily a hierarchical list of labels.  For example, a Windows explorer like display, where the file extensions are hidden.  The label for two files can be identical, but the file names themselves are different.





I don't like the overloaded nature of the "-columns" argument -- 
either an integer representing the number of columns or a list 
of symbolic column names.  But I *really* like the ability to 
have named columns, and if we had separate -numbercolumns 
and -columnnames options it'd be more work for users and for 
the widget to ensure they were always consistent.


Following the "everything-is-a-string" paradigm, I would just say that all columns are named; period.  This also gives you a default header label.





Specifying "-displaycolumns {}" (the default) means that all 
columns are shown, in order.  There is no way to say "do not 
display any columns". 

The -height option should really specify the desired number of 
visible items, not the height in pixels.  I'm not sure what 
units '-width' ought to take.


I've never liked "item" based sizing.  It leads to funky window resizing behavior.





The return value of [$tree identify $x $y] is a hairball. 

I'm not too sure about the names 'open' and 'close'. 



How about "expand" and "collapse".



I'm also not too sure about the number of widget commands; 
maybe some of these should be merged into a subensemble. 


Other stuff to think about: 

Item states: there are a few item states that the tree indicator 
element should be aware of, so it can select an appropriate display 
based on whether the node is open or closed, and whether or not 
it's a leaf element.  None of the currently-defined TTK_STATE_* 
flags really match those concepts well.  "selected" might serve 
for open/closed, except that we also want to support listbox-style 
selections.  I'm using the USER1 and USER2 state flags internally 
right now for open and nonleaf, respectively; but there really 
ought to be a mechanism for assigning meaningful names. 


Comments?


I would also like to see an incremental or dynamic interface that allows for support of larger datasets.  We have an interface on our tree that is comprised of three configure options:  -querycommand, -querysizecmd, -queryblocksize.  The -querycommand is called whenever a node is expanded (opened), and is passed the node id ("" for root).  The command will return a list of items which are the children for that node.  Each element of the list is a list of triples, one triple for each column.  The triple is comprised of {<label> <tags> <image>}.  The label and image should be obvious.  The tags element is a list of flags, the primary ones being "branch", or "leaf".

In the simple case, all the children for a node are returned when requested.  To handle large datasets, the -querysizecmd and -queryblocksize are used.  Before calling -querycommand, the -querysizecmd is called to calculate the number of children for the node.  Then the -querycommand is called with two additional parameters, a start index and a count (count comes from -queryblocksize).  The callback will only return "count" items starting at the start index.  The widget determines what range is needed based on the scroll offset and only makes enough calls to get the data needed to satisfy the display.  Also, the command callbacks support % substitution for node (%n), start (%s), and count (%c).

I find this interface easier to use then the traditional "$w insert ..." interface, especially when the data is dynamic.  A simple trigger can be used to cause the widget to re-acquire the data from the callbacks.

-Brian





--Joe English 

  jen...@fl... <mailto:jen...@fl...>  


------------------------------------------------------- 
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 
Project Admins to receive an Apple iPod Mini FREE for your judgement on 
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php <http://sf.net/ppc_contest.php>  
_______________________________________________ 
Tktable-tile-dev mailing list 
Tkt...@li... <mailto:Tkt...@li...>  
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev <https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev>  


-- 

-------------------------------------------------------------

--                 Model Technology Inc.                   --

-- 8005 SW Boeckman Road                  503.685.7000 tel --

-- Wilsonville, OR 97070 USA              503.685.0921 fax --

-------------------------------------------------------------

-- Technical support ............ mailto:su...@mo... <mailto:su...@mo...>  --

-- Sales and marketing info ....... mailto:sa...@mo... <mailto:sa...@mo...>  --

-- Licensing .................... mailto:li...@mo... <mailto:li...@mo...>  --

-- Home Page ........................ http://www.model.com <http://www.model.com>  --

-- AIM ........................................ bgriffin42 --

-------------------------------------------------------------

> As a starting point for discussion, I've posted
> a strawmanpage here:
>
>     <URL: http://tktable.sourceforge.net/tile/doc/treeview.html >
>
> The documented interface is still incomplete, but I think
> it's a pretty good start.  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.

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

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

> Stuff that's missing:
>
> + Need to keep track of an "active" or "focussed" item;
> + Support for selections;
> + Drag and drop support, or (more likely) a foundation upon which
>   drag and drop support could be built.

Foundation. Useful for other widgets as well - drag/drop entry values ...

> + A way to specify column headings, column widgths, and other stuff

> + Might want to be able to turn different components on and off:
>   column headings, open/close indicators, tree "connecting lines",
>   maybe even the tree labels to support "pure" multicolumn listboxes.

Yes.

> Some things I like about this design:
>
> Separate -columns and -displaycolumns options make it easy
> to hide or reorder columns without having to change all the
> item -values.
>
> It works as a plain tree (leave -columns empty and don't
> supply -values for any items), and -- almost -- as a plain
> multicolumn listbox (create all items as children of the root
> and leave out -text and -image.)
>
> Some things I'm not too keen on:
>
>     $tree insert $index $parent $itemid ? ... options ... ?
>
> I copied this straight from the BWidget Tree, just to have a
> starting point.  I'm not sure how useful user-supplied node
> IDs are; it may be better to just use widget-generated integers
> like the canvas does.  This would reduce the number of required
> arguments from 3 to 2; and since then it's incompatible with
> BWidget anyway we can swap the order of the first two arguments
> and make it:
>
> 	$tree insert $parent $index ?... options ... ?
>
> which seems more natural to me.

> I don't like the overloaded nature of the "-columns" argument --
> either an integer representing the number of columns or a list
> of symbolic column names.  But I *really* like the ability to
> have named columns, and if we had separate -numbercolumns
> and -columnnames options it'd be more work for users and for
> the widget to ensure they were always consistent.
>
> Specifying "-displaycolumns {}" (the default) means that all
> columns are shown, in order.  There is no way to say "do not
> display any columns".
>
> The -height option should really specify the desired number of
> visible items, not the height in pixels.  I'm not sure what
> units '-width' ought to take.
>
> The return value of [$tree identify $x $y] is a hairball.

A bit yes.

> I'm not too sure about the names 'open' and 'close'.

	Alt. names: 'show' and 'hide'.

> I'm also not too sure about the number of widget commands;
> maybe some of these should be merged into a subensemble.

All the item specific commands maybe ?


> Other stuff to think about:
>
> Item states: there are a few item states that the tree indicator
> element should be aware of, so it can select an appropriate display
> based on whether the node is open or closed, and whether or not
> it's a leaf element.  None of the currently-defined TTK_STATE_*
> flags really match those concepts well.  "selected" might serve
> for open/closed, except that we also want to support listbox-style
> selections.  I'm using the USER1 and USER2 state flags internally
> right now for open and nonleaf, respectively; but there really
> ought to be a mechanism for assigning meaningful names.
>
>
> Comments?

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)

If not, just snip this part from any reply.



Thanks for starting the work.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

I have only briefly looked at the manpage, but I had a
couple of comments off the bat (see below):

--- Joe English <jen...@fl...> wrote:

> 
> As a starting point for discussion, I've posted
> a strawmanpage here:
> 
>     <URL:
>
http://tktable.sourceforge.net/tile/doc/treeview.html
> >
> 
> The documented interface is still incomplete, but I
> think
> it's a pretty good start.  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 :-)
> 
> Stuff that's missing:
> 
> + Need to keep track of an "active" or "focussed"
> item;
> + Support for selections;
> + Drag and drop support, or (more likely) a
> foundation upon which
>   drag and drop support could be built.
> + A way to specify column headings, column widgths,
> and other stuff
> + Might want to be able to turn different components
> on and off:
>   column headings, open/close indicators, tree
> "connecting lines",
>   maybe even the tree labels to support "pure"
> multicolumn listboxes.
> 
> 
> Some things I like about this design:
> 
> Separate -columns and -displaycolumns options make
> it easy
> to hide or reorder columns without having to change
> all the
> item -values.
> 
> It works as a plain tree (leave -columns empty and
> don't
> supply -values for any items), and -- almost -- as a
> plain
> multicolumn listbox (create all items as children of
> the root
> and leave out -text and -image.)
> 
> Some things I'm not too keen on:
> 
>     $tree insert $index $parent $itemid ? ...
> options ... ?
> 
> I copied this straight from the BWidget Tree, just
> to have a
> starting point.  I'm not sure how useful
> user-supplied node
> IDs are; it may be better to just use
> widget-generated integers
> like the canvas does.  This would reduce the number
> of required
> arguments from 3 to 2; and since then it's
> incompatible with
> BWidget anyway we can swap the order of the first
> two arguments
> and make it:
> 

One thing I use explicit node names for is so that I
can identify the node during callbacks (i.e. when
selected). Think of it as "client data" in the node
name. I'm not sure if this is the right way to do this
or not, but I find it comes in handy. Of course, one
could just keep a reference to the node id (generated
from treeview) and client data in a separate
structure, but I kind of like keeping it together. Not
sure if I am explainging this well enough...

One other thing that I think is missing, is a way to
find out if a node exists. In BWidgets, it would be:

$widget exists <nodename>

I actually do use this in existing code. I didn't see
anything comparable in the treeview manpage (unless I
missed it). Of course, a catch could be used, but I
like the explicit "exists" command.

that's it for now...thanks for the work.

    --brett
 

As a starting point for discussion, I've posted
a strawmanpage here:

    <URL: http://tktable.sourceforge.net/tile/doc/treeview.html >

The documented interface is still incomplete, but I think
it's a pretty good start.  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 :-)

Stuff that's missing:

+ Need to keep track of an "active" or "focussed" item;
+ Support for selections;
+ Drag and drop support, or (more likely) a foundation upon which
  drag and drop support could be built.
+ A way to specify column headings, column widgths, and other stuff
+ Might want to be able to turn different components on and off:
  column headings, open/close indicators, tree "connecting lines",
  maybe even the tree labels to support "pure" multicolumn listboxes.


Some things I like about this design:

Separate -columns and -displaycolumns options make it easy
to hide or reorder columns without having to change all the
item -values.

It works as a plain tree (leave -columns empty and don't
supply -values for any items), and -- almost -- as a plain
multicolumn listbox (create all items as children of the root
and leave out -text and -image.)

Some things I'm not too keen on:

    $tree insert $index $parent $itemid ? ... options ... ?

I copied this straight from the BWidget Tree, just to have a
starting point.  I'm not sure how useful user-supplied node
IDs are; it may be better to just use widget-generated integers
like the canvas does.  This would reduce the number of required
arguments from 3 to 2; and since then it's incompatible with
BWidget anyway we can swap the order of the first two arguments
and make it:

	$tree insert $parent $index ?... options ... ?

which seems more natural to me.

I don't like the overloaded nature of the "-columns" argument --
either an integer representing the number of columns or a list
of symbolic column names.  But I *really* like the ability to
have named columns, and if we had separate -numbercolumns
and -columnnames options it'd be more work for users and for
the widget to ensure they were always consistent.

Specifying "-displaycolumns {}" (the default) means that all
columns are shown, in order.  There is no way to say "do not
display any columns".

The -height option should really specify the desired number of
visible items, not the height in pixels.  I'm not sure what
units '-width' ought to take.

The return value of [$tree identify $x $y] is a hairball.

I'm not too sure about the names 'open' and 'close'.
I'm also not too sure about the number of widget commands;
maybe some of these should be merged into a subensemble.


Other stuff to think about:

Item states: there are a few item states that the tree indicator
element should be aware of, so it can select an appropriate display
based on whether the node is open or closed, and whether or not
it's a leaf element.  None of the currently-defined TTK_STATE_*
flags really match those concepts well.  "selected" might serve
for open/closed, except that we also want to support listbox-style
selections.  I'm using the USER1 and USER2 state flags internally
right now for open and nonleaf, respectively; but there really
ought to be a mechanism for assigning meaningful names.


Comments?


--Joe English

  jen...@fl...

Jeff Hobbs wrote:

 > Bryan Oakley wrote:
>>I think what I'd like is to see tktreectrl in the core but hidden (or 
>>maybe not...). We could then graft some APIs on top so that it can be 
>>treated as several different widgets. At the very least there would be a 
>>tree API and another API for the listbox-like features 
>>(showing rows and columns of icons or text).
> 
> 
> Someone just mentioned this point on the tile-dev list again,
> with reference to your earlier clt comments.

I'll keep planting the seed until something sprouts :-)

To make this work we'd need to modify tktreectrl to take a -class 
option, so the API layer could do something like "tktreectrl -class Tree 
..." to create the actual widget. Then it wouldn't take much more than 
an "interp alias {} tree {} tktreectrl -class Tree" and we're off to the 
races. Of course, we'd have to tweak the bindings or bindtags, etc...

With that, the bulk of the work would be in writing man pages broken up 
by class, and only documenting the options that make sense in a 
particular context.

Andreas Kupries wrote:

> AFAIU tktreectrl is also based on a combination of hierarchy and
> multi-column.
>
> See http://tktreectrl.sourceforge.net/
>
> However while tktreectrl is a very nice tree widget, very flexible, its API
> is also quite complicated.

I've looked at tktreecntl.  I can't figure out how to use it.
It's got too many features.

> A tree as powerful as tktreectrl with a more
> rational or understandable API would be my wish.

If "as powerful as tktreectrl" and "with an understandable API"
are not mutually exclusive, that'd be great :-)  Any ideas?


--Joe English

  jen...@fl...

--- Jeff Hobbs <je...@Ac...> wrote:

> > > It's only fault is the complexity of the API. 
> Is this unavoidable due 
> > > to the complexity of the widget, or is this
> something that post-dev 
> > > experience and more use with the widget can help
> to rationalize?
> > 
> >     I'm playing with it now to try and answer some
> of those 
> > questions, but someone else with more experience
> with the 
> > widget might be able to better answer them.  You
> seem to have 
> > worked with it a little, Jeff. 
> > Any initial musings you'd like to share?
> 
> > PS:
> > treectrl.n     108k
> 
> text.n:    78K
> canvas.n:  73K
> tktable.n: 60K.
> 
> Are those hard to understand?  Well, for some, but
> eventually
> you work through it all.  I think at least the
> treectrl docs
> are mostly complete, even if a few more samples
> might help
> explain things.
> 
> As for initial impressions, it has some elements of
> the canvas
> without using the same naming conventions.  It gets
> a bit
> blurry if you add tile with its new naming
> conventions into
> the mix, as treectrl has "elements" and "styles". 
> It's kind
> of Tix like in some respects.  Tim may be the best
> person to
> answer that.
> 

I kind of liked the suggestion previously stated on a
different thread (I think CLT maybe)...I think it was
Bryan. Create wrappers around tktreectrl for different
widgets; i.e. create a wrapper widget for a
multi-column widget, create a wrapper for a Tree
widget, etc. This could all be done in Tcl (I think).
Of course, you would still have the original
tktreectrl widget, for those non common uses.

I'm not saying we should not try to enhance the API.
We should (if needed). But, if I just need a Tree
widget, I don't want to monkey around configuring it
to act like a Tree widget, every time I need a Tree
widget.

my $0.02

    --brett

> > It's only fault is the complexity of the API.  Is this unavoidable due 
> > to the complexity of the widget, or is this something that post-dev 
> > experience and more use with the widget can help to rationalize?
> 
>     I'm playing with it now to try and answer some of those 
> questions, but someone else with more experience with the 
> widget might be able to better answer them.  You seem to have 
> worked with it a little, Jeff. 
> Any initial musings you'd like to share?

> PS:
> treectrl.n     108k

text.n:    78K
canvas.n:  73K
tktable.n: 60K.

Are those hard to understand?  Well, for some, but eventually
you work through it all.  I think at least the treectrl docs
are mostly complete, even if a few more samples might help
explain things.

As for initial impressions, it has some elements of the canvas
without using the same naming conventions.  It gets a bit
blurry if you add tile with its new naming conventions into
the mix, as treectrl has "elements" and "styles".  It's kind
of Tix like in some respects.  Tim may be the best person to
answer that.

Jeff

> It's only fault is the complexity of the API.  Is this
> unavoidable due to the complexity of the widget, or is this
> something that post-dev experience and more use with the widget
> can help to rationalize?

    I'm playing with it now to try and answer some of those questions, but
someone else with more experience with the widget might be able to
better answer them.  You seem to have worked with it a little, Jeff. 
Any initial musings you'd like to share?

D

PS:

treectrl.html  149k
treectrl.man   101k
treectrl.n     108k

Be afraid.

Larry McVoy wrote:
> > > The power of the widget is unrivaled in what it does as far as I 
> > > know. It just needs a lot of work to make it more... Tcl'ish.
> 
> I'd love to see this widget integrated.  On the other hand, 
> we have started playing with the bwidgets tree widget and 
> seems to have a pretty nice API. Bryan, you want to review 
> your likes/dislikes of each of these?  You've 
> used them more than anyone I know.

[adding in Tim Baker, primary treectrl author - we are
discussing the addition of a tree widget that would be tracked
for the core]

I'd like to see what Bryan has to say, but the BWidgets tree
widget is a 1 week hack compared to the features of the treectrl
widget.  When you go to
    http://tktreectrl.sourceforge.net/
note that in all the picture, both the left *and* right panes
are treectrl widgets.  We use it in the VFS Explorer, which you
can see here:
    http://aspn.activestate.com/ASPN/docs/Tcl_Dev_Kit/TclVFSE.html
Again, left and right are treectrl widgets - it is both a tree
and a multicolumn listbox.  It has element styles and views, etc.

It's only fault is the complexity of the API.  Is this
unavoidable due to the complexity of the widget, or is this
something that post-dev experience and more use with the widget
can help to rationalize?

Jeff

> > AFAIU tktreectrl is also based on a combination of hierarchy and 
> > multi-column.
> >
> > See http://tktreectrl.sourceforge.net/
> >
> > However while tktreectrl is a very nice tree widget, very flexible, 
> > its API is also quite complicated. A tree as powerful as tktreectrl 
> > with a more rational or understandable API would be my wish.
> 
>     If I recall correctly, tktreectrl had a pretty 
> complicated interface to allow for specifying the elements, 
> options and things of each individual column or row.  Since 
> Tile already has a very good system for defining elements of 
> widgets and the like, I'd like to see tktreectrl translated 
> into using the system we already have in place. 
> The power of the widget is unrivaled in what it does as far 
> as I know.  It just needs a lot of work to make it more... Tcl'ish.

I strongly agree with this sentiment.  Perhaps it is possible
to bring treectrl into the tile dev effort.  I don't think
that you would want to attempt a different tree from scratch.
It would take a good chunk of someone's time to analyze
treectrl with respect to tile stuff though (must less treectrl
by itself).

Jeff

--- Larry McVoy <lm...@bi...> wrote:

> On Wed, Sep 22, 2004 at 10:36:03AM -0700, Andreas
> Kupries wrote:
> > 
> > > > AFAIU tktreectrl is also based on a
> combination of hierarchy and
> > > > multi-column.
> > > >
> > > > See http://tktreectrl.sourceforge.net/
> > > >
> > > > However while tktreectrl is a very nice tree
> widget, very flexible, its
> > API
> > > > is also quite complicated. A tree as powerful
> as tktreectrl with a more
> > > > rational or understandable API would be my
> wish.
> > >
> > > If I recall correctly, tktreectrl had a pretty
> complicated interface
> > > to allow for specifying the elements, options
> and things of each
> > > individual column or row.
> > 
> > Yep. I did work with it, and the best I could do
> was to use the demos and
> > modify them for what I wanted. Slightly. Part of
> the problem is that the
> > docs do not explain the relations between all the
> pieces very well either.
> > 
> > > Since Tile already has a very good system
> > > for defining elements of widgets and the like,
> I'd like to see
> > > tktreectrl translated into using the system we
> already have in place.
> > 
> > If that is possible, we should go for that, IMHO.
> > 
> > > The power of the widget is unrivaled in what it
> does as far as I know.
> > > It just needs a lot of work to make it more...
> Tcl'ish.
> 
> I'd love to see this widget integrated.  On the
> other hand, we have started
> playing with the bwidgets tree widget and seems to
> have a pretty nice API.
> Bryan, you want to review your likes/dislikes of
> each of these?  You've 
> used them more than anyone I know.

Yes, the Tree widget in BWidgets is nice, but it lacks
the multi-column feature that Joe is proposing. But
yes, looking at the Tree api might be a good starting
point. Might want to look at mclistbox and tablelist
as well for the multi-column api...

I really, really, really, would like to see a
Tree/multicolumn widget!
  
    --brett

> I'd love to see this widget integrated.  On the other hand, we have
> started
> playing with the bwidgets tree widget and seems to have a pretty nice API.
> Bryan, you want to review your likes/dislikes of each of these?  You've
> used them more than anyone I know.

    I think the BWidget Tree is very intuitive and simple in its
interface, and I use it all the time.  It doesn't fill the requirement
for the multi-column listbox that tktreectrl does, but I think tktable
can basically accomplish everything I need without it.

    Obviously, any Tree widget written in C is going to perform a lot
better and faster than the BWidget alternative, but what are we really
looking for?  Are we looking for a Tree/Multi-column listbox as Joe is
suggesting, or can we live with Tktable and a Tree widget serving two
separate purposes?

    I, personally, think tktreectrl is too powerful not to start from
there.  Having just downloaded it and started looking at it again
though, it definitely needs some work in the usability camp.  It'd
take forever to make a tree that performed exactly as you wanted with
all those freakin' subcommands, styles, elements, etc...

    Until there's a core widget, I stick with BWidgets for all my daily
tasks.  I have quite a few new widgets here on the ol' laptop that
need to get updated so others can use them.  Have to find the time...
*sigh*

D

On Wed, Sep 22, 2004 at 10:36:03AM -0700, Andreas Kupries wrote:
> 
> > > AFAIU tktreectrl is also based on a combination of hierarchy and
> > > multi-column.
> > >
> > > See http://tktreectrl.sourceforge.net/
> > >
> > > However while tktreectrl is a very nice tree widget, very flexible, its
> API
> > > is also quite complicated. A tree as powerful as tktreectrl with a more
> > > rational or understandable API would be my wish.
> >
> > If I recall correctly, tktreectrl had a pretty complicated interface
> > to allow for specifying the elements, options and things of each
> > individual column or row.
> 
> Yep. I did work with it, and the best I could do was to use the demos and
> modify them for what I wanted. Slightly. Part of the problem is that the
> docs do not explain the relations between all the pieces very well either.
> 
> > Since Tile already has a very good system
> > for defining elements of widgets and the like, I'd like to see
> > tktreectrl translated into using the system we already have in place.
> 
> If that is possible, we should go for that, IMHO.
> 
> > The power of the widget is unrivaled in what it does as far as I know.
> > It just needs a lot of work to make it more... Tcl'ish.

I'd love to see this widget integrated.  On the other hand, we have started
playing with the bwidgets tree widget and seems to have a pretty nice API.
Bryan, you want to review your likes/dislikes of each of these?  You've 
used them more than anyone I know.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

> > AFAIU tktreectrl is also based on a combination of hierarchy and
> > multi-column.
> >
> > See http://tktreectrl.sourceforge.net/
> >
> > However while tktreectrl is a very nice tree widget, very flexible, its
API
> > is also quite complicated. A tree as powerful as tktreectrl with a more
> > rational or understandable API would be my wish.
>
> If I recall correctly, tktreectrl had a pretty complicated interface
> to allow for specifying the elements, options and things of each
> individual column or row.

Yep. I did work with it, and the best I could do was to use the demos and
modify them for what I wanted. Slightly. Part of the problem is that the
docs do not explain the relations between all the pieces very well either.

> Since Tile already has a very good system
> for defining elements of widgets and the like, I'd like to see
> tktreectrl translated into using the system we already have in place.

If that is possible, we should go for that, IMHO.

> The power of the widget is unrivaled in what it does as far as I know.
> It just needs a lot of work to make it more... Tcl'ish.


--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

> AFAIU tktreectrl is also based on a combination of hierarchy and
> multi-column.
>
> See http://tktreectrl.sourceforge.net/
>
> However while tktreectrl is a very nice tree widget, very flexible, its
> API
> is also quite complicated. A tree as powerful as tktreectrl with a more
> rational or understandable API would be my wish.

    If I recall correctly, tktreectrl had a pretty complicated interface
to allow for specifying the elements, options and things of each
individual column or row.  Since Tile already has a very good system
for defining elements of widgets and the like, I'd like to see
tktreectrl translated into using the system we already have in place. 
The power of the widget is unrivaled in what it does as far as I know.
 It just needs a lot of work to make it more... Tcl'ish.

    Any other ideas?

D

> AFAIU tktreectrl is also based on a combination of hierarchy and
> multi-column.
>
> See http://tktreectrl.sourceforge.net/
>
> However while tktreectrl is a very nice tree widget, very flexible, its
> API
> is also quite complicated. A tree as powerful as tktreectrl with a more
> rational or understandable API would be my wish.

    If I recall correctly, tktreectrl had a pretty complicated interface
to allow for specifying the elements, options and things of each
individual column or row.  Since Tile already has a very good system
for defining elements of widgets and the like, I'd like to see
tktreectrl translated into using the system we already have in place. 
The power of the widget is unrivaled in what it does as far as I know.
 It just needs a lot of work to make it more... Tcl'ish.

    Any other ideas?

D

> Any thoughts on what the API for a tree widget ought to look like?
> I've got a few ideas, which I'll post later, but want to hear what
> others have to say first.  What I have in mind is a hierarchical,
> multi-column widget; something like a combination of a BWidget Tree
> and an MCListbox.

AFAIU tktreectrl is also based on a combination of hierarchy and
multi-column.

See http://tktreectrl.sourceforge.net/

However while tktreectrl is a very nice tree widget, very flexible, its API
is also quite complicated. A tree as powerful as tktreectrl with a more
rational or understandable API would be my wish.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491

Joe English wrote:
> Any thoughts on what the API for a tree widget ought to look like?

Not really. My apps haven't really been in a position to make a lot of
use of that sort of thing in the past, so I've not paid a lot of
attention. It might be an idea to look at the API used by the Swing
JTree component; that's what I've had most contact with in this area and
it seems to work at least acceptably, in that it was very easy to get
something going well enough that I stopped looking at the API. :^)

Donal.