Menu
▾
▴
tktable-tile-dev
|
From: Joe E. <jen...@fl...> - 2004-09-27 16:45:11
|
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.
|
|
From: Brett S. <bre...@ya...> - 2004-09-27 17:27:06
|
>
> + -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
|
|
From: Joe E. <jen...@fl...> - 2004-09-28 02:06:44
|
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... |
|
From: Bryan O. <br...@bi...> - 2004-09-27 18:02:09
|
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.
|
|
From: Donal K. F. <don...@ma...> - 2004-09-27 20:09:41
|
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. |
|
From: Bryan O. <br...@bi...> - 2004-09-27 20:43:03
|
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) :-) |
|
From: Larry M. <lm...@bi...> - 2004-09-27 21:24:22
|
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 |
|
From: Brett S. <bre...@ya...> - 2004-09-27 21:55:50
|
--- 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 :) |
|
From: Joe E. <jen...@fl...> - 2004-09-28 03:05:40
|
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... |
|
From: Bryan O. <br...@bi...> - 2004-09-28 04:32:43
|
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. |
|
From: Joe E. <jen...@fl...> - 2004-09-28 16:24:18
|
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... |
|
From: Damon C. <da...@tc...> - 2004-09-27 17:59:23
|
>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 |
|
From: Bryan O. <br...@bi...> - 2004-09-27 18:36:21
|
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? |
|
From: Joe E. <jen...@fl...> - 2004-09-28 03:16:34
|
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... |
