tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] Tree API draft round 2

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

Bryan Oakley wrote:
> Joe English wrote:
> > (I've looked at how other toolkits/widgets implement interactive
> > resizing, and I'm quite convinced that you *really* don't want to
> > do anything too clever here.  The ones that try to be clever
> > are confusing to the user, get confused themselves, or both.
> > If anyone knows of an exception, let me know...)
>
> Mozilla's newsreader has an example of fixed width columns. I have a
> column with a image (to designate junk mail status), and if I drag the
> right edge it's the same as if I dragged the left edge (ie: the column
> to the left grows rather than growing the fixed-width column). It makes
> sense, but again, it's not strictly necessary.

Hm.  Just checked Evolution, it might also be an exception.
Dragging a column separator resizes the column immediately
to the left, columns to the left of that one stay the same size,
and columns to the right grow and shrink proportionally
so everything still fits.  Also subject to minimum-width and
fixed-width column constraints.  This seems better.  (Rhythmbox, 
OTOH, is doing something I can't quite figure out...)


--Joe English

  jen...@fl...

Re: [Tile-dev] Strawman Tree widget API

[Donal K. F. <don...@ma...>]

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.

Re: [Tile-dev] Tree API draft round 2

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

Joe English wrote:


>>I'd like an option to specify whether a column is to be of fixed width
>>or not (assuming that columns can be interactively resized). This
>>wouldn't be a showstopper, but would lead to a more polished UI.
> 
> 
> I had planned to support a minimum size for columns (preferably
> calculated automatically from the column heading, user-specified
> as a last resort), but not a maximum size.  Dragging the border
> between two column headings will resize the column to the left,
> limited by the minimum size.  That's all.
> 

I won't lose any sleep over this.

> (I've looked at how other toolkits/widgets implement interactive
> resizing, and I'm quite convinced that you *really* don't want to
> do anything too clever here.  The ones that try to be clever
> are confusing to the user, get confused themselves, or both.
> If anyone knows of an exception, let me know...)
> 

Mozilla's newsreader has an example of fixed width columns. I have a
column with a image (to designate junk mail status), and if I drag the
right edge it's the same as if I dragged the left edge (ie: the column
to the left grows rather than growing the fixed-width column). It makes 
sense, but again, it's not strictly necessary.

Re: [Tile-dev] Tree API draft round 2

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

Damon Courtney wrote:

>     Is this really a tree view or a multi-column view?

It should be able to handle both.

> So far, I'm seeing more to do with multi-column features and 
> not so much for a tree.

Well, there's parent, children, next, prev, move, insert, and the 
fact that items are arranged hierarchically...

> Some features in BWidget's tree that I'd definitely want to see 
> in this one:
> 
> -showlines
> -deltax
> -deltay
> -crossopenimage
> -crosscloseimage
> 
>     I realize these are mostly just features to affect the display of 
> the tree, but I think they're pretty important for making a tree do lots 
> of different duties.

All of these (and more) are or will be supported, but 
like Bryan said in his followup most of them are in the
style system and not specified as widget options.

> Also, the ability to display an image next to each 
> item is crucial and not something I see in the current draft.

Items have an '-image' option.


--Joe English

  jen...@fl...

Re: [Tile-dev] Tree API draft round 2

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

Bryan Oakley wrote:
>
> Do you have a sample implementation built on top of some other widget?

No, but I do have one built directly atop the Tile theme engine :-)
Coming soon to the CVS repository; it's ~40% complete now.

(A treeview widget was the last major test case for the theme engine --
if this one is implementable I'm going to call the interface fully-cooked.
So far so good; I think I can see how to iron out the rest of the
rough spots now.)

> I think the "column" subcommand should be "columnconfigure" since it is
> conceptually similar to entryconfigure or itemconfigure subcommands in
> other widgets.

I had 'columnconfigure' originally, as well as 'itemconfigure'.
See earlier message [1] for why it uses the shorter names now.
This is a break with Tk conventions, but I think it's a
justifiable deviation.


> It would be nice to specify where the image is to appear in a column
> heading. Sometimes it makes sense to put it on the left (think of an
> icon that represents the type of data), sometimes on the right (think of
> a up/down triangle to represent sorting).

This is *probably* best handled with custom styles.
At the moment, the treeview widget doesn't fully support
the -style option (notebooks and scrollbars don't either) --
this is one of the aforementioned rough spots.


> I'd like an option to specify whether a column is to be of fixed width
> or not (assuming that columns can be interactively resized). This
> wouldn't be a showstopper, but would lead to a more polished UI.

I had planned to support a minimum size for columns (preferably
calculated automatically from the column heading, user-specified
as a last resort), but not a maximum size.  Dragging the border
between two column headings will resize the column to the left,
limited by the minimum size.  That's all.

(I've looked at how other toolkits/widgets implement interactive
resizing, and I'm quite convinced that you *really* don't want to
do anything too clever here.  The ones that try to be clever
are confusing to the user, get confused themselves, or both.
If anyone knows of an exception, let me know...)


> Here are suggestions for the obvious virtual events:
>
> <<TreeviewSelect>>	- when an item is selected

Or more generally, whenever the selection changes.

> <<TreeviewOpen>> 	- when an item is opened
> <<TreeviewClose>> 	- when an item is closed
>
> The open and close events create an interesting problem, which is how to
> present to the procedure being called which item was just opened.

Yep :-)

> Since
> the event mechanism doesn't provide a way to attach metadata we need to
> come up with a way to query which item was just opened (.treeview cget
> -lastopen?).

TIP #165 provides a user-data field for virtual events.
Only available in Tk 8.5, though, and I'd like to stay
compatible with 8.4.  (We'll use it if it's there, of course,
but for 8.4 applications there needs to be another data path.)

> In lieu of all that, the treeview widget could have options to specify
> procs to call when something happens (eg: .treeview configure
> -opencommand whatever -closecommand whatever...).



We could also set the 'active' item before generating
<<TreeviewOpen>> and <<TreeviewClose>> events and pass
the data that way.  

> I prefer virtual events if we can solve the metadata problem.

Me too...

[1] http://sourceforge.net/mailarchive/message.php?msg_id=9616698

--Joe English

  jen...@fl...

Re: [Tile-dev] Tree API draft round 2

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

Brett Schwarz wrote:
> >     + -columns is [...] a read-only option now, and can only be
> > 	  set at widget creation time [*].
>
> Ok, I definitely would like to see this not readonly.

OK; will change it back.

> I know that makes your job tougher,

Not terribly; the code is already _mostly_ in place
to handle this.  The only troublesome area is error
recovery: if you set -columns to something that's
incompatible with -displaycolumns, it raises an
error (which is OK) and leaves the widget in an
inconsistent state (which is not).

This is a recoverable condition and won't lead to
any crashes, but it violates one of the invariants
that widgets are supposed to maintain.


--Joe English

  jen...@fl...

Re: [Tile-dev] Tree API draft round 2

[Brett S. <bre...@ya...>]

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

> On Mon, Sep 27, 2004 at 03:42:55PM -0500, Bryan
> Oakley wrote:
> > Donal K. Fellows wrote:
> > >Bryan Oakley wrote:
> > >
> > >>That, or we take this as an opportunity to
> modify "event generate" to 
> > >>accept a "-metadata" option, eg:
> > >
> > >
> > >
> > >Already *solved* in Tcl 8.5. TIP#165 gives [event
> generate] a -data 
> > >option which you retrieve with the %d
> substitution in a binding script. :^D
> > >
> > 
> > Bryan does a happy dance (after first turning the
> camera off) :-)
> 
> Oh, come one, I want to see the dance, hell, we all
> want to see it right?  :-)

just as long as it's not the macarena :)

Re: [Tile-dev] Tree API draft round 2

[Larry M. <lm...@bi...>]

On Mon, Sep 27, 2004 at 03:42:55PM -0500, Bryan Oakley wrote:
> Donal K. Fellows wrote:
> >Bryan Oakley wrote:
> >
> >>That, or we take this as an opportunity to modify "event generate" to 
> >>accept a "-metadata" option, eg:
> >
> >
> >
> >Already *solved* in Tcl 8.5. TIP#165 gives [event generate] a -data 
> >option which you retrieve with the %d substitution in a binding script. :^D
> >
> 
> Bryan does a happy dance (after first turning the camera off) :-)

Oh, come one, I want to see the dance, hell, we all want to see it right?  :-)
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [Tile-dev] Tree API draft round 2

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

Donal K. Fellows wrote:
> Bryan Oakley wrote:
> 
>> That, or we take this as an opportunity to modify "event generate" to 
>> accept a "-metadata" option, eg:
> 
> 
> 
> Already *solved* in Tcl 8.5. TIP#165 gives [event generate] a -data 
> option which you retrieve with the %d substitution in a binding script. :^D
> 

Bryan does a happy dance (after first turning the camera off) :-)

Re: [Tile-dev] Tree API draft round 2

[Donal K. F. <don...@ma...>]

Bryan Oakley wrote:

> That, or we take this as an opportunity to modify "event generate" to 
> accept a "-metadata" option, eg:


Already *solved* in Tcl 8.5. TIP#165 gives [event generate] a -data 
option which you retrieve with the %d substitution in a binding script. :^D

Donal.

Re: [Tile-dev] Tree API draft round 2

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

Damon Courtney wrote:

>    Is this really a tree view or a multi-column view?  So far, I'm 
> seeing more to do with multi-column features and not so much for a 
> tree.  Some features in BWidget's tree that I'd definitely want to see 
> in this one:
> 
> -showlines
> -deltax
> -deltay
> -crossopenimage
> -crosscloseimage
> 

Wouldn't all (or most) of the above be addressable with custom styles 
provided by the tile engine?


>    I realize these are mostly just features to affect the display of the 
> tree, but I think they're pretty important for making a tree do lots of 
> different duties.  Also, the ability to display an image next to each 
> item is crucial and not something I see in the current draft.  

Each item has a -image option for specifying an image. Won't that do 
what you want?

Re: [Tile-dev] Tree API draft round 2

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

Joe English wrote:

> Did some more work on this over the weekend.  I'm pretty happy
> with the current data model; the primitives provided seem just
> about right.

This is a nice step in the right direction. I like the ability to 
detatch items and move them about without having to destroy and recreate 
them.

Do you have a sample implementation built on top of some other widget? 
If not, I might see how easy (or not) it would be to combin snit and 
tktreectrl to mock this sucker up.

I think the "column" subcommand should be "columnconfigure" since it is 
conceptually similar to entryconfigure or itemconfigure subcommands in 
other widgets.

It would be nice to specify where the image is to appear in a column 
heading. Sometimes it makes sense to put it on the left (think of an 
icon that represents the type of data), sometimes on the right (think of 
a up/down triangle to represent sorting).

I'd like an option to specify whether a column is to be of fixed width 
or not (assuming that columns can be interactively resized). This 
wouldn't be a showstopper, but would lead to a more polished UI.

Here are suggestions for the obvious virtual events:

<<TreeviewSelect>>	- when an item is selected
<<TreeviewOpen>> 	- when an item is opened
<<TreeviewClose>> 	- when an item is closed

The open and close events create an interesting problem, which is how to 
present to the procedure being called which item was just opened. Since 
the event mechanism doesn't provide a way to attach metadata we need to 
come up with a way to query which item was just opened (.treeview cget 
-lastopen?).

That, or we take this as an opportunity to modify "event generate" to 
accept a "-metadata" option, eg:

     event generate .tree <<TreeviewOpen>> -metadata $item
     ...
     bind .tree <<TreeviewOpen>> {openHandler %M}
     proc openHandler {metadata} {
         puts "hey, item $metadata was opened!"
     }

In lieu of all that, the treeview widget could have options to specify 
procs to call when something happens (eg: .treeview configure 
-opencommand whatever -closecommand whatever...). I prefer virtual 
events if we can solve the metadata problem.

The main need for this is to be able to build a tree dynamically. For 
example, there's no need to create children for a directory unless the 
user opens that directory. The way to do that is to have a proc called 
whenever an item is opened for the first time.

Re: [Tile-dev] Tree API draft round 2

[Damon C. <da...@tc...>]

>If anyone has use cases for the widget, now would be a good
>time to post them.
>
>
>Updated manpage here:
>
>    <URL: http://tktable.sourceforge.net/tile/doc/treeview.html >
>  
>
    Is this really a tree view or a multi-column view?  So far, I'm 
seeing more to do with multi-column features and not so much for a 
tree.  Some features in BWidget's tree that I'd definitely want to see 
in this one:

-showlines
-deltax
-deltay
-crossopenimage
-crosscloseimage

    I realize these are mostly just features to affect the display of 
the tree, but I think they're pretty important for making a tree do lots 
of different duties.  Also, the ability to display an image next to each 
item is crucial and not something I see in the current draft.  Again, I 
just see more work being done on the multi-column side and less 
attention being paid to the tree side.  Are we really trying to 
accomplish both in one widget?

D

Re: [Tile-dev] Tree API draft round 2

[Brett S. <bre...@ya...>]

> 
>     + -columns is always a list of column names. 
> It's also
>       a read-only option now, and can only be set at
> widget
>       creation time [*].
> 

Ok, I definitely would like to see this not readonly.
I know that makes your job tougher, but I do change
column names frequently. For example, I can just
create one mult-column listbox, and use that same
widget for different views. I do this now with
tablelist. For example, I have a Tree widget on the
left pane, in which the user can select a node to view
the data for that node. I have a mc-listbox on the
right pane that displays this data. Instead of having
a widget for each node, I just delete out the
headings/data in the currect mc-listbox view, and
display the data for the new node that was selected.

I hope I explained that clear enough...

thanks,

    --brett

[Tile-dev] Tree API draft round 2

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

Did some more work on this over the weekend.  I'm pretty happy
with the current data model; the primitives provided seem just
about right.

The display and interaction model needs work next.
At a minimum, the widget should support an 'active' item
and a set of 'selected' items like the listbox widget.
We might want to support column selections as well.

It also needs a set of virtual events and/or callbacks
to report interactions, and a way to associate commands
with column headings, plus whatever internal mechanisms
are necessary to make headings look and act like pushbuttons.

Jeff Hobbs made a suggestion about item tags.  I'm waiting
for him to elaborate on that idea :-) but it sounds like
a promising approach.

If anyone has use cases for the widget, now would be a good
time to post them.


Updated manpage here:

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

New stuff since first draft:

    + Added 'column' command to query/configure column attributes.

    + Added 'set' command to query/set item values.

    + Added 'exists' command

    + Added 'move', 'next', and 'prev' commands


Changes since first draft:

    + The 'insert' command now has the form:

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

      This worked out better.

    + 'remove' is now 'detach' as per AKU's suggestion.

    + 'delete' now takes a list of items.

    + 'children' takes an optional fourth argument; if supplied
      it replaces the list of children.

    + -columns is always a list of column names.  It's also
      a read-only option now, and can only be set at widget
      creation time [*].

    + The -width option is gone; instead the width is calculated
      from the sum of the widths of the -displaycolumns and
      the tree column #0 [**].

    + As discussed earlier, 'itemconfigure' and 'itemcget'
      have been replaced with an 'item' data accessor.
      'open', 'close', and 'opened' widget commands have been
      replaced with '-open' item option.

    + Clarified meaning of out-of-range $index values:
      if $index < 0, insert at the beginning, if >= #children
      append to end.


--Joe English

  jen...@fl...


[*] The main reason for making -columns readonly is to prevent
the widget from getting into an inconsistent state under certain
error conditions.  If this is a problem, I'll try to figure
out how to avoid the inconsistency or just live with it --
it's not a fatal condition, just a possibly confusing one.

[**] -width will probably need to be added back in again later;
I anticipate problems with interactive column resizing.

Re: [Tile-dev] Strawman Tree widget API

[Brett S. <bre...@ya...>]

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

Re: [Tile-dev] Strawman Tree widget API

[Brett S. <bre...@ya...>]

> 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

Re: [Tile-dev] Strawman Tree widget API

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

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

Re: [Tile-dev] Strawman Tree widget API

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

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

[Tile-dev] Tree API -- item identifiers

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

Well, I tried switching to the form

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

returning an integer item ID.  This didn't work out as
well as I thought it would.

Use cases where you want application-defined node IDs --
like the test suite -- really do become a lot more painful.
There's an odd asymmetry in that you *have* to name columns
but you *can't* name items.  The implementation and test suite
didn't really get any simpler, it just traded one set of special
cases for another one.

This form lacks discoverability: when you're playing with
the widget from an interactive wish prompt, you end up
saying things like:

    $tree insert 91 3 -text foo

Since item ids and indexes are both integers, this gets confusing.
The only real benefit is that it saves some memory [*].

So for now I've reverted to the BWidget form,

    $tree insert $index $parent $id ...options...

I'm going to try this next:

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

If "-id" isn't supplied, the widget will generate one
of the form "ixxxx", where the xes are hex digits.


--Joe English

  jen...@fl...

[*] I haven't bothered measuring, but: items currently take
10 words plus a hash table entry plus a TCL_STRING_KEY; with
integer IDs the last can be changed to a TCL_ONE_WORD_KEY
which is "free" with the hash entry.

Re: [Tile-dev] Strawman Tree widget API

[Griffin, B. <bgr...@mo...>]

Joe English wrote:

>
> Brian Griffin wrote:
>
> > 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.
>

How would you handle scrollbar sizing with virtual events?  The widget 
needs to know how many entries are in the tree without having any of the 
actual data.  Providing "empty" data doesn't really solve the problem 
considering datasets on the order of 10e7.  (e.g. number gates on a chip)

This is a somewhat rhetorical question, because:

> I've filed away your description, it'll be a good use case
> for further API design.
>

This may be an area I can work on once the initial implementation is 
available.

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

Re: [Tile-dev] Strawman Tree widget API

[Donal K. F. <don...@ma...>]

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.

Re: [Tile-dev] Strawman Tree widget API

[Donal K. F. <don...@ma...>]

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.

Re: [Tile-dev] Strawman Tree widget API

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

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

Re: [Tile-dev] Strawman Tree widget API

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

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