Menu
▾
▴
tktable-tile-dev
|
From: Joe E. <jen...@fl...> - 2004-09-23 16:10:48
|
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...
|
|
From: Brett S. <bre...@ya...> - 2004-09-23 18:08:59
|
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 |
|
From: Joe E. <jen...@fl...> - 2004-09-24 03:14:59
|
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... |
|
From: Brett S. <bre...@ya...> - 2004-09-24 04:09:47
|
--- 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 ...
|
|
From: Joe E. <jen...@fl...> - 2004-09-25 07:19:26
|
Brett Schwarz wrote: > 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: Note that you can put as many clientData attributes as you want in the -values list, by leaving those elements out of the -displaycolumns. I just added a [$tree set $item $column ?newValue?] command for easy access, too... --Joe English jen...@fl... |
|
From: Brett S. <bre...@ya...> - 2004-09-25 16:07:36
|
--- Joe English <jen...@fl...> wrote:
>
> Brett Schwarz wrote:
>
> > 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:
>
> Note that you can put as many clientData attributes
> as you want in the -values list, by leaving those
> elements out of the -displaycolumns.
>
Ah, good point. I actually do use this method with
tablelist.
Speaking of which, is Csaba Nemethi (author of
tablelist) on this mailing list? If not, maybe we
should copy him on this thread???? He might have some
insight. I know Bryan is already on this list
(mclistbox).
--brett
|
|
From: Donal K. F. <don...@ma...> - 2004-09-24 08:44:54
|
Joe English wrote: > 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... Having to mess around with node identifiers was one of the bits that made using the BWidget tree much more complex when I used it. A scheme more like the canvas's ids would make much more sense to me for the simple cases. "Make common things simple..." > [Brett Schwarz wrote:] >> 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 the canvas, setting bindings (the only kind of callback supported) on an item is a separate step from creating the item. >> $widget exists <nodename> > Would this still be useful if node IDs weren't user-supplied? Yes. Donal. |
|
From: Andreas K. <and...@ac...> - 2004-09-23 18:31:07
|
> 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 |
|
From: Joe E. <jen...@fl...> - 2004-09-24 03:27:27
|
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... |
|
From: Bryan O. <br...@bi...> - 2004-09-24 03:52:45
|
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.
|
|
From: Joe E. <jen...@fl...> - 2004-09-25 07:11:06
|
Bryan Oakley wrote:
> Joe English wrote:
> > 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"
> ...
> }
There's also the column -values, plus auxilliary data like
the open/closed state and the -image (those might be part of
the display model instead of the data model).
Also: tree location paths don't make for good keys (as the
above example seems to do), since they change when earlier
items are inserted and deleted.
The tree data model *might* fit in a nested dictionary,
with distinguished keys -text and -children and column names
as the remaining keys. But you don't get variable traces
on individual dictionary elements (that's the whole point
of dicts), so you'd have to reconstitute the entire
display model whenever the linked -variable changes.
An array -variable would probably work better. But no matter
what scheme is used to wedge the tree structure into an array,
it's highly unlikely to match any application data structures so
it'll still take work to schlep data in and out. IOW, it's not
like an [entry] or a [checkbutton] where the linked -variable
is directly usable. (At least that's been my experience with
Tktable -- I *never* have data in the exact form that it wants,
it always requires a simple transformation of some sort.)
Any compelling use cases for this?
--Joe English
jen...@fl...
|
|
From: Brett S. <bre...@ya...> - 2004-09-25 16:04:03
|
> An array -variable would probably work better. But
> no matter
> what scheme is used to wedge the tree structure into
> an array,
> it's highly unlikely to match any application data
> structures so
> it'll still take work to schlep data in and out.
> IOW, it's not
> like an [entry] or a [checkbutton] where the linked
> -variable
> is directly usable. (At least that's been my
> experience with
> Tktable -- I *never* have data in the exact form
> that it wants,
> it always requires a simple transformation of some
> sort.)
>
> Any compelling use cases for this?
>
I haven't thought it through totally, but I think I
agree with you. I also have the same experiences with
Tktable, and I think we would run into a similiar
situation here.
--brett
|
|
From: Donal K. F. <don...@ma...> - 2004-09-28 09:54:39
|
Joe English wrote: > There's also the column -values, plus auxilliary data like > the open/closed state and the -image (those might be part of > the display model instead of the data model). Looking at Java (yes, we should learn from them as this is an area where what they've got works tolerably well IME) http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/tree/TreeModel.html we see that they do this sort of separation, keeping the auxiliary data somewhere else (within the JTree component itself as far as I can tell). However, I'm not at all sure that the -image is best part of the aux data. Donal. |
|
From: Andreas K. <aku...@sh...> - 2004-09-24 04:15:34
|
> 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/>
-------------------------------------------------------------------------------
|
|
From: Brian G. <bri...@ea...> - 2004-09-23 23:09:05
|
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 -- ------------------------------------------------------------- |
|
From: Joe E. <jen...@fl...> - 2004-09-24 05:00:37
|
Brian Griffin wrote: > Headings need to be buttons with -commands, and support label/image > combinations Like the up arrow/down arrow sort direction indicator seen on the right side of the header in some interfaces? Pretty easy to add. Sort direction indicators probably ought to be themable; the best way to handle this might be to specify a collection of "stock images" that applications could reference and themes could override. > > 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? The indexes are relative to the parent; they're part of the data model, not the display model, so expanding/collapsing earlier nodes won't affect the position. > > [...] > > 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. [...] > > Without a UID, how do you find something in the tree? There's still UIDs, they'd just be generated automatically by [$tree insert ...]. Either sequential integers or opaque tokens like "item119". > > 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. [...] > > 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. I'm *really* tempted to do this. The main reasons for allowing the user to just specify the number of columns is that it seemed slightly more intuitive (to get 5 columns, say "-columns 5"); and the data might not have homogeneous columns, in which case there wouldn't be a meaningful identifier for each column. But I think I'll do it anyway. If anyone complains loudly enough, we can put it back in. > > [...] > > 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. I hadn't planned on implementing gridded geometry; the window would still resize smoothly. Just that when you create a tree widget you can specify the desired number of visible rows instead of the height in pixels. This seems more useful to me. (As precedents, the listbox and text widgets work this way.) > 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: [... description elided ...] I can see where this would be useful, but I don't want to use a callback-style interface by default for supplying data. Instead, the widget should generate a rich enough set of virtual events that you can implement this sort of thing on top of it. I've filed away your description, it'll be a good use case for further API design. --Joe English jen...@fl... |
|
From: Donal K. F. <don...@ma...> - 2004-09-24 09:01:35
|
Joe English wrote:
> Brian Griffin wrote:
>>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.
> I'm *really* tempted to do this.
>
> The main reasons for allowing the user to just specify the
> number of columns is that it seemed slightly more intuitive
> (to get 5 columns, say "-columns 5"); and the data might not
> have homogeneous columns, in which case there wouldn't be a
> meaningful identifier for each column.
Do columns have to have *unique* names? If not, all it requires is
something like this:
-columns [lrepeat 5 {}]
This would indicate that the -displaycolumns option ought to be a list
of integers, but that would probably make it easier for the tablelist
class bindings to manipulate in the first place...
Donal.
|
|
From: Joe E. <jen...@fl...> - 2004-09-24 05:41:31
|
Not mentioned explicitly (but sort of implied by the separate
'itemconfigure' and 'itemcget' commands), the 3-argument form:
$tree itemconfigure $item
returns a list of 5/2-tuples just like widget 'configure' commands do.
It occurred to me that this is completely unnecessary;
[$tree itemconfigure] should return a simple dictionary
of -option/value pairs, just like [font configure] does.
The 4-argument form can replace [$tree itemcget].
Further, the names can be shortened to just the noun part
"item" and "column":
$tree item $item ?-option ?-value ?-option value...???
$tree column $column ...
are generalized data accessors for item and column attributes.
This is a clear win. I'm going to introduce a
* * * POTENTIAL INCOMPATIBILITY * * *
and replace [$notebook tabconfigure] / [$notebook tabcget]
with [$notebook tab], using the same pattern.
Further simplifications: "-open" can be an item option, (I keep
flip-flopping between "open" and "expand[ed]") removing the
need for [$tree open/expand], [$tree close/collapse] and [$tree
opened/expanded]. This is another win: three fewer commands,
and users can set the open/closed state at item creation time.
Plus, I can dump several screensful of boilerplate code.
This makes me happy :-)
--Joe English
jen...@fl...
|
