Menu
▾
▴
tktable-tile-dev
|
From: Joe E. <jen...@fl...> - 2004-09-22 06:44:28
|
Any thoughts on what the API for a tree widget ought to look like? I've got a few ideas, which I'll post later, but want to hear what others have to say first. What I have in mind is a hierarchical, multi-column widget; something like a combination of a BWidget Tree and an MCListbox. --Joe English jen...@fl... |
|
From: Donal K. F. <don...@ma...> - 2004-09-22 07:06:40
|
Joe English wrote: > Any thoughts on what the API for a tree widget ought to look like? Not really. My apps haven't really been in a position to make a lot of use of that sort of thing in the past, so I've not paid a lot of attention. It might be an idea to look at the API used by the Swing JTree component; that's what I've had most contact with in this area and it seems to work at least acceptably, in that it was very easy to get something going well enough that I stopped looking at the API. :^) Donal. |
|
From: Andreas K. <and...@Ac...> - 2004-09-22 17:20:25
|
> Any thoughts on what the API for a tree widget ought to look like? > I've got a few ideas, which I'll post later, but want to hear what > others have to say first. What I have in mind is a hierarchical, > multi-column widget; something like a combination of a BWidget Tree > and an MCListbox. AFAIU tktreectrl is also based on a combination of hierarchy and multi-column. See http://tktreectrl.sourceforge.net/ However while tktreectrl is a very nice tree widget, very flexible, its API is also quite complicated. A tree as powerful as tktreectrl with a more rational or understandable API would be my wish. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com, a division of Sophos Tel: +1 604 484 6491 |
|
From: Damon C. <da...@tc...> - 2004-09-22 17:30:46
|
> AFAIU tktreectrl is also based on a combination of hierarchy and > multi-column. > > See http://tktreectrl.sourceforge.net/ > > However while tktreectrl is a very nice tree widget, very flexible, its > API > is also quite complicated. A tree as powerful as tktreectrl with a more > rational or understandable API would be my wish. If I recall correctly, tktreectrl had a pretty complicated interface to allow for specifying the elements, options and things of each individual column or row. Since Tile already has a very good system for defining elements of widgets and the like, I'd like to see tktreectrl translated into using the system we already have in place. The power of the widget is unrivaled in what it does as far as I know. It just needs a lot of work to make it more... Tcl'ish. Any other ideas? D |
|
From: Jeff H. <je...@ac...> - 2004-09-22 17:53:49
|
> > AFAIU tktreectrl is also based on a combination of hierarchy and > > multi-column. > > > > See http://tktreectrl.sourceforge.net/ > > > > However while tktreectrl is a very nice tree widget, very flexible, > > its API is also quite complicated. A tree as powerful as tktreectrl > > with a more rational or understandable API would be my wish. > > If I recall correctly, tktreectrl had a pretty > complicated interface to allow for specifying the elements, > options and things of each individual column or row. Since > Tile already has a very good system for defining elements of > widgets and the like, I'd like to see tktreectrl translated > into using the system we already have in place. > The power of the widget is unrivaled in what it does as far > as I know. It just needs a lot of work to make it more... Tcl'ish. I strongly agree with this sentiment. Perhaps it is possible to bring treectrl into the tile dev effort. I don't think that you would want to attempt a different tree from scratch. It would take a good chunk of someone's time to analyze treectrl with respect to tile stuff though (must less treectrl by itself). Jeff |
|
From: Damon C. <da...@tc...> - 2004-09-22 17:31:59
|
> AFAIU tktreectrl is also based on a combination of hierarchy and > multi-column. > > See http://tktreectrl.sourceforge.net/ > > However while tktreectrl is a very nice tree widget, very flexible, its > API > is also quite complicated. A tree as powerful as tktreectrl with a more > rational or understandable API would be my wish. If I recall correctly, tktreectrl had a pretty complicated interface to allow for specifying the elements, options and things of each individual column or row. Since Tile already has a very good system for defining elements of widgets and the like, I'd like to see tktreectrl translated into using the system we already have in place. The power of the widget is unrivaled in what it does as far as I know. It just needs a lot of work to make it more... Tcl'ish. Any other ideas? D |
|
From: Andreas K. <and...@Ac...> - 2004-09-22 17:36:20
|
> > AFAIU tktreectrl is also based on a combination of hierarchy and > > multi-column. > > > > See http://tktreectrl.sourceforge.net/ > > > > However while tktreectrl is a very nice tree widget, very flexible, its API > > is also quite complicated. A tree as powerful as tktreectrl with a more > > rational or understandable API would be my wish. > > If I recall correctly, tktreectrl had a pretty complicated interface > to allow for specifying the elements, options and things of each > individual column or row. Yep. I did work with it, and the best I could do was to use the demos and modify them for what I wanted. Slightly. Part of the problem is that the docs do not explain the relations between all the pieces very well either. > Since Tile already has a very good system > for defining elements of widgets and the like, I'd like to see > tktreectrl translated into using the system we already have in place. If that is possible, we should go for that, IMHO. > The power of the widget is unrivaled in what it does as far as I know. > It just needs a lot of work to make it more... Tcl'ish. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com, a division of Sophos Tel: +1 604 484 6491 |
|
From: Larry M. <lm...@bi...> - 2004-09-22 17:39:16
|
On Wed, Sep 22, 2004 at 10:36:03AM -0700, Andreas Kupries wrote: > > > > AFAIU tktreectrl is also based on a combination of hierarchy and > > > multi-column. > > > > > > See http://tktreectrl.sourceforge.net/ > > > > > > However while tktreectrl is a very nice tree widget, very flexible, its > API > > > is also quite complicated. A tree as powerful as tktreectrl with a more > > > rational or understandable API would be my wish. > > > > If I recall correctly, tktreectrl had a pretty complicated interface > > to allow for specifying the elements, options and things of each > > individual column or row. > > Yep. I did work with it, and the best I could do was to use the demos and > modify them for what I wanted. Slightly. Part of the problem is that the > docs do not explain the relations between all the pieces very well either. > > > Since Tile already has a very good system > > for defining elements of widgets and the like, I'd like to see > > tktreectrl translated into using the system we already have in place. > > If that is possible, we should go for that, IMHO. > > > The power of the widget is unrivaled in what it does as far as I know. > > It just needs a lot of work to make it more... Tcl'ish. I'd love to see this widget integrated. On the other hand, we have started playing with the bwidgets tree widget and seems to have a pretty nice API. Bryan, you want to review your likes/dislikes of each of these? You've used them more than anyone I know. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
|
From: Damon C. <da...@tc...> - 2004-09-22 17:49:53
|
> I'd love to see this widget integrated. On the other hand, we have
> started
> playing with the bwidgets tree widget and seems to have a pretty nice API.
> Bryan, you want to review your likes/dislikes of each of these? You've
> used them more than anyone I know.
I think the BWidget Tree is very intuitive and simple in its
interface, and I use it all the time. It doesn't fill the requirement
for the multi-column listbox that tktreectrl does, but I think tktable
can basically accomplish everything I need without it.
Obviously, any Tree widget written in C is going to perform a lot
better and faster than the BWidget alternative, but what are we really
looking for? Are we looking for a Tree/Multi-column listbox as Joe is
suggesting, or can we live with Tktable and a Tree widget serving two
separate purposes?
I, personally, think tktreectrl is too powerful not to start from
there. Having just downloaded it and started looking at it again
though, it definitely needs some work in the usability camp. It'd
take forever to make a tree that performed exactly as you wanted with
all those freakin' subcommands, styles, elements, etc...
Until there's a core widget, I stick with BWidgets for all my daily
tasks. I have quite a few new widgets here on the ol' laptop that
need to get updated so others can use them. Have to find the time...
*sigh*
D
|
|
From: Brett S. <bre...@ya...> - 2004-09-22 17:51:56
|
--- Larry McVoy <lm...@bi...> wrote: > On Wed, Sep 22, 2004 at 10:36:03AM -0700, Andreas > Kupries wrote: > > > > > > AFAIU tktreectrl is also based on a > combination of hierarchy and > > > > multi-column. > > > > > > > > See http://tktreectrl.sourceforge.net/ > > > > > > > > However while tktreectrl is a very nice tree > widget, very flexible, its > > API > > > > is also quite complicated. A tree as powerful > as tktreectrl with a more > > > > rational or understandable API would be my > wish. > > > > > > If I recall correctly, tktreectrl had a pretty > complicated interface > > > to allow for specifying the elements, options > and things of each > > > individual column or row. > > > > Yep. I did work with it, and the best I could do > was to use the demos and > > modify them for what I wanted. Slightly. Part of > the problem is that the > > docs do not explain the relations between all the > pieces very well either. > > > > > Since Tile already has a very good system > > > for defining elements of widgets and the like, > I'd like to see > > > tktreectrl translated into using the system we > already have in place. > > > > If that is possible, we should go for that, IMHO. > > > > > The power of the widget is unrivaled in what it > does as far as I know. > > > It just needs a lot of work to make it more... > Tcl'ish. > > I'd love to see this widget integrated. On the > other hand, we have started > playing with the bwidgets tree widget and seems to > have a pretty nice API. > Bryan, you want to review your likes/dislikes of > each of these? You've > used them more than anyone I know. Yes, the Tree widget in BWidgets is nice, but it lacks the multi-column feature that Joe is proposing. But yes, looking at the Tree api might be a good starting point. Might want to look at mclistbox and tablelist as well for the multi-column api... I really, really, really, would like to see a Tree/multicolumn widget! --brett |
|
From: Jeff H. <je...@ac...> - 2004-09-22 17:54:02
|
Larry McVoy wrote:
> > > The power of the widget is unrivaled in what it does as far as I
> > > know. It just needs a lot of work to make it more... Tcl'ish.
>
> I'd love to see this widget integrated. On the other hand,
> we have started playing with the bwidgets tree widget and
> seems to have a pretty nice API. Bryan, you want to review
> your likes/dislikes of each of these? You've
> used them more than anyone I know.
[adding in Tim Baker, primary treectrl author - we are
discussing the addition of a tree widget that would be tracked
for the core]
I'd like to see what Bryan has to say, but the BWidgets tree
widget is a 1 week hack compared to the features of the treectrl
widget. When you go to
http://tktreectrl.sourceforge.net/
note that in all the picture, both the left *and* right panes
are treectrl widgets. We use it in the VFS Explorer, which you
can see here:
http://aspn.activestate.com/ASPN/docs/Tcl_Dev_Kit/TclVFSE.html
Again, left and right are treectrl widgets - it is both a tree
and a multicolumn listbox. It has element styles and views, etc.
It's only fault is the complexity of the API. Is this
unavoidable due to the complexity of the widget, or is this
something that post-dev experience and more use with the widget
can help to rationalize?
Jeff
|
|
From: Damon C. <da...@tc...> - 2004-09-22 18:07:07
|
> It's only fault is the complexity of the API. Is this
> unavoidable due to the complexity of the widget, or is this
> something that post-dev experience and more use with the widget
> can help to rationalize?
I'm playing with it now to try and answer some of those questions, but
someone else with more experience with the widget might be able to
better answer them. You seem to have worked with it a little, Jeff.
Any initial musings you'd like to share?
D
PS:
treectrl.html 149k
treectrl.man 101k
treectrl.n 108k
Be afraid.
|
|
From: Jeff H. <je...@Ac...> - 2004-09-22 18:20:46
|
> > It's only fault is the complexity of the API. Is this unavoidable due > > to the complexity of the widget, or is this something that post-dev > > experience and more use with the widget can help to rationalize? > > I'm playing with it now to try and answer some of those > questions, but someone else with more experience with the > widget might be able to better answer them. You seem to have > worked with it a little, Jeff. > Any initial musings you'd like to share? > PS: > treectrl.n 108k text.n: 78K canvas.n: 73K tktable.n: 60K. Are those hard to understand? Well, for some, but eventually you work through it all. I think at least the treectrl docs are mostly complete, even if a few more samples might help explain things. As for initial impressions, it has some elements of the canvas without using the same naming conventions. It gets a bit blurry if you add tile with its new naming conventions into the mix, as treectrl has "elements" and "styles". It's kind of Tix like in some respects. Tim may be the best person to answer that. Jeff |
|
From: Brett S. <bre...@ya...> - 2004-09-22 18:35:39
|
--- Jeff Hobbs <je...@Ac...> wrote:
> > > It's only fault is the complexity of the API.
> Is this unavoidable due
> > > to the complexity of the widget, or is this
> something that post-dev
> > > experience and more use with the widget can help
> to rationalize?
> >
> > I'm playing with it now to try and answer some
> of those
> > questions, but someone else with more experience
> with the
> > widget might be able to better answer them. You
> seem to have
> > worked with it a little, Jeff.
> > Any initial musings you'd like to share?
>
> > PS:
> > treectrl.n 108k
>
> text.n: 78K
> canvas.n: 73K
> tktable.n: 60K.
>
> Are those hard to understand? Well, for some, but
> eventually
> you work through it all. I think at least the
> treectrl docs
> are mostly complete, even if a few more samples
> might help
> explain things.
>
> As for initial impressions, it has some elements of
> the canvas
> without using the same naming conventions. It gets
> a bit
> blurry if you add tile with its new naming
> conventions into
> the mix, as treectrl has "elements" and "styles".
> It's kind
> of Tix like in some respects. Tim may be the best
> person to
> answer that.
>
I kind of liked the suggestion previously stated on a
different thread (I think CLT maybe)...I think it was
Bryan. Create wrappers around tktreectrl for different
widgets; i.e. create a wrapper widget for a
multi-column widget, create a wrapper for a Tree
widget, etc. This could all be done in Tcl (I think).
Of course, you would still have the original
tktreectrl widget, for those non common uses.
I'm not saying we should not try to enhance the API.
We should (if needed). But, if I just need a Tree
widget, I don't want to monkey around configuring it
to act like a Tree widget, every time I need a Tree
widget.
my $0.02
--brett
|
|
From: Joe E. <jen...@fl...> - 2004-09-22 18:52:35
|
Andreas Kupries wrote: > AFAIU tktreectrl is also based on a combination of hierarchy and > multi-column. > > See http://tktreectrl.sourceforge.net/ > > However while tktreectrl is a very nice tree widget, very flexible, its API > is also quite complicated. I've looked at tktreecntl. I can't figure out how to use it. It's got too many features. > A tree as powerful as tktreectrl with a more > rational or understandable API would be my wish. If "as powerful as tktreectrl" and "with an understandable API" are not mutually exclusive, that'd be great :-) Any ideas? --Joe English jen...@fl... |
