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