Menu
▾
▴
tktable-tile-dev
|
From: Tim B. <tre...@ho...> - 2006-11-21 23:18:02
|
Jeff Hobbs wrote: > > Brett Schwarz wrote: >> I like the idea of waiting for 8.6 to get a good solution for >> a tree widget in the core (whether that's an enhanced >> treeview or a wrangled up tktreectrl). Even though I would >> have loved to see it part of 8.5, I'd rather wait for a good >> and solid solution. > > That would address the situation *if* we felt that treectrl served as a > useful > base for "more generic" treeview widget. That is what I am not certain > of. > > I did verify that Tim's latest changes greatly reduce memory (ActivePerl > PPM > steady state reduced from ~66MB to ~43MB, with just an upgrade to treectrl > 2.2). However, if I only needed what a "simpler" treeview would provide, > and > it provided it with a memory size of ~20MB for the same app ... does that > not > justify a simpler, dedicated widget? > > Therein lies the real question - if we strongly feel that a simple > dedicated > and mega configurable tree widgets (2 separate) are both valuable, let's > get > treeview in 8.5, and treectrl in 8.6. Is it only the [style] and [element] commands that blows treectrl out of the "simple" space into "mega-configurable"? The high memory requirements are mostly a result of styles and elements. Whenever people comment that treectrl is difficult to use I start brainstorming alternate APIs. It always comes down to a question of how much control over the appearance of items is desired. > (BTW Tim - I had to modify the configure.ac to kick treectrl to 2.2 - any > reason not to commit that?) Done. -- Tim Baker |
|
From: Jeff H. <je...@ac...> - 2006-11-22 00:04:05
|
Tim Baker wrote: > Jeff Hobbs wrote: > > 2.2). However, if I only needed what a "simpler" treeview would = provide,=20 > > and > > it provided it with a memory size of ~20MB for the same app ... does = that=20 > > not justify a simpler, dedicated widget? > > > > Therein lies the real question - if we strongly feel that a simple dedicated > > and mega configurable tree widgets (2 separate) are both valuable, = let's=20 > > get treeview in 8.5, and treectrl in 8.6. >=20 > Is it only the [style] and [element] commands that blows=20 > treectrl out of the "simple" space into "mega-configurable"?=20 > The high memory requirements are mostly a result of styles=20 > and elements. Whenever people comment that treectrl > is difficult to use I start brainstorming alternate APIs. It=20 > always comes down to a question of how much control over the > appearance of items is desired. Therein does lie the question. To be honest, I have very little = exposure to the treeview widget, whereas I have done quite a bit with treectrl. I = have some comfort that ActiveState's use of treectrl has stressed it to find = weak points (and resolve them for the most part). I don't know much about treeview's track record. I do know that the = little bits I've seen always had /something/ wrong with them. The demos/dirbrowser.tcl doesn't scroll right on Windows (adds too much = space at the end), doesn't seem to handle the +/- stuff right, the headers have = several issues ... Anecdotally, for those who have had treeview and treectrl available to them, where treectrl was too complicated to master, they = more often turned to BWidget's tree (or tablelist if appropriate) than use = treeview due to its lack of features. I will deconstruct the treeview "oversimplicity" from the dir browser perspective, since I have done directory views with treectrl. * The handling of the sort arrow is a built-in feature in treectrl. In treeview (like tktable), you would have to manage the same yourself with = the -image stuff (which can only be placed left of the label). * The columns - how do you specify which one has weight? Resize and = shrink behavior? This is all possible in treectrl, but doesn't appear to be in treeview. * Is it possible with treeview to give a full single column a background without tagging each item (as one would do to indicate the current sort column)? * No x scrolling in treeview? * Auto-ellipsing, or other detection on truncation for treeview? * They do both have column and element visibility control. * Any row/column spanning in treeview? Except for the last one, the rest would all be desirable in the most = generic of directory browsers. While it is certainly possible to address the = above issues, is there time to do it? What about taking that time and working = on ttk::dialog, ttk::toplevel, ttk::menu, etc? Jeff |
|
From: Will D. <Wil...@jp...> - 2006-11-22 15:54:51
|
Jeff, You keep talking about directory browsing, which is an application for which a tree is useful but which involves considerably more than basic tree behavior. treectrl supports this, and treeview doesn't. I think the basic problem here is that although both widgets have "tree" in their name, treectrl *isn't* a "tree" widget. You can use it for that; but it's really something more powerful, and perhaps should have a name that indicates that. Frankly, I can see a place in Tk/Ttk for both widgets. A simple one, akin to the standard Tk listbox, and a complex but vastly more powerful one. Will On Nov 21, 2006, at 4:02 PM, Jeff Hobbs wrote: > Tim Baker wrote: >> Jeff Hobbs wrote: >>> 2.2). However, if I only needed what a "simpler" treeview would >>> provide, >>> and >>> it provided it with a memory size of ~20MB for the same app ... does >>> that >>> not justify a simpler, dedicated widget? >>> >>> Therein lies the real question - if we strongly feel that a simple > dedicated >>> and mega configurable tree widgets (2 separate) are both valuable, >>> let's >>> get treeview in 8.5, and treectrl in 8.6. >> >> Is it only the [style] and [element] commands that blows >> treectrl out of the "simple" space into "mega-configurable"? >> The high memory requirements are mostly a result of styles >> and elements. Whenever people comment that treectrl >> is difficult to use I start brainstorming alternate APIs. It >> always comes down to a question of how much control over the >> appearance of items is desired. > > Therein does lie the question. To be honest, I have very little > exposure to > the treeview widget, whereas I have done quite a bit with treectrl. I > have > some comfort that ActiveState's use of treectrl has stressed it to > find weak > points (and resolve them for the most part). > > I don't know much about treeview's track record. I do know that the > little > bits I've seen always had /something/ wrong with them. The > demos/dirbrowser.tcl doesn't scroll right on Windows (adds too much > space at > the end), doesn't seem to handle the +/- stuff right, the headers have > several > issues ... Anecdotally, for those who have had treeview and treectrl > available to them, where treectrl was too complicated to master, they > more > often turned to BWidget's tree (or tablelist if appropriate) than use > treeview > due to its lack of features. > > I will deconstruct the treeview "oversimplicity" from the dir browser > perspective, since I have done directory views with treectrl. > > * The handling of the sort arrow is a built-in feature in treectrl. In > treeview (like tktable), you would have to manage the same yourself > with the > -image stuff (which can only be placed left of the label). > > * The columns - how do you specify which one has weight? Resize and > shrink > behavior? This is all possible in treectrl, but doesn't appear to be > in > treeview. > > * Is it possible with treeview to give a full single column a > background > without tagging each item (as one would do to indicate the current sort > column)? > > * No x scrolling in treeview? > > * Auto-ellipsing, or other detection on truncation for treeview? > > * They do both have column and element visibility control. > > * Any row/column spanning in treeview? > > Except for the last one, the rest would all be desirable in the most > generic > of directory browsers. While it is certainly possible to address the > above > issues, is there time to do it? What about taking that time and > working on > ttk::dialog, ttk::toplevel, ttk::menu, etc? > > Jeff > > > ----------------------------------------------------------------------- > -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Tktable-tile-dev mailing list > Tkt...@li... > https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev > > ------------------------------------------------------------------------ Will Duquette, JPL | Wil...@jp... But I speak only | http://eis.jpl.nasa.gov/~will (JPL Use Only) for myself. | It's amazing what you can do with the right tools. |
|
From: Jeff H. <je...@ac...> - 2006-11-22 16:42:58
|
Will, Your points are in general correct, but overlook the direct remarks I made below. Those features are certainly required for a decent dir browser, but they are necessary for many other type of apps as well. The lack of these in treeview is why people have turned to pure Tcl alternatives even when treeview was available. If you want to look at treeview as a multicolumn listbox, then it really fails in 2 areas - no x scrolling and the inability to control stretch/shrink of columns. Joe has said he likely won't have the time to address these before 8.5.0, and thus I don't think it serves the core much to distract with the treeview. Jeff Will Duquette wrote: > Jeff, > > You keep talking about directory browsing, which is an application > for which a tree is useful but which involves considerably more than > basic tree behavior. treectrl supports this, and treeview doesn't. > > I think the basic problem here is that although both widgets have > "tree" in their name, treectrl *isn't* a "tree" widget. You can use > it for that; but it's really something more powerful, and perhaps should > have a name that indicates that. > > Frankly, I can see a place in Tk/Ttk for both widgets. A simple one, > akin to the standard Tk listbox, and a complex but vastly more powerful > one. > > Will > > On Nov 21, 2006, at 4:02 PM, Jeff Hobbs wrote: > >> Tim Baker wrote: >>> Jeff Hobbs wrote: >>>> 2.2). However, if I only needed what a "simpler" treeview would >>>> provide, >>>> and >>>> it provided it with a memory size of ~20MB for the same app ... does >>>> that >>>> not justify a simpler, dedicated widget? >>>> >>>> Therein lies the real question - if we strongly feel that a simple >> dedicated >>>> and mega configurable tree widgets (2 separate) are both valuable, >>>> let's >>>> get treeview in 8.5, and treectrl in 8.6. >>> >>> Is it only the [style] and [element] commands that blows >>> treectrl out of the "simple" space into "mega-configurable"? >>> The high memory requirements are mostly a result of styles >>> and elements. Whenever people comment that treectrl >>> is difficult to use I start brainstorming alternate APIs. It >>> always comes down to a question of how much control over the >>> appearance of items is desired. >> >> Therein does lie the question. To be honest, I have very little >> exposure to >> the treeview widget, whereas I have done quite a bit with treectrl. I >> have >> some comfort that ActiveState's use of treectrl has stressed it to >> find weak >> points (and resolve them for the most part). >> >> I don't know much about treeview's track record. I do know that the >> little >> bits I've seen always had /something/ wrong with them. The >> demos/dirbrowser.tcl doesn't scroll right on Windows (adds too much >> space at >> the end), doesn't seem to handle the +/- stuff right, the headers have >> several >> issues ... Anecdotally, for those who have had treeview and treectrl >> available to them, where treectrl was too complicated to master, they >> more >> often turned to BWidget's tree (or tablelist if appropriate) than use >> treeview >> due to its lack of features. >> >> I will deconstruct the treeview "oversimplicity" from the dir browser >> perspective, since I have done directory views with treectrl. >> >> * The handling of the sort arrow is a built-in feature in treectrl. In >> treeview (like tktable), you would have to manage the same yourself >> with the >> -image stuff (which can only be placed left of the label). >> >> * The columns - how do you specify which one has weight? Resize and >> shrink >> behavior? This is all possible in treectrl, but doesn't appear to be in >> treeview. >> >> * Is it possible with treeview to give a full single column a background >> without tagging each item (as one would do to indicate the current sort >> column)? >> >> * No x scrolling in treeview? >> >> * Auto-ellipsing, or other detection on truncation for treeview? >> >> * They do both have column and element visibility control. >> >> * Any row/column spanning in treeview? >> >> Except for the last one, the rest would all be desirable in the most >> generic >> of directory browsers. While it is certainly possible to address the >> above >> issues, is there time to do it? What about taking that time and >> working on >> ttk::dialog, ttk::toplevel, ttk::menu, etc? >> >> Jeff |
|
From: Csaba N. <csa...@t-...> - 2006-11-22 21:17:10
|
Jeff Hobbs schrieb: > Will, > > Your points are in general correct, but overlook the direct remarks I > made below. Those features are certainly required for a decent dir > browser, but they are necessary for many other type of apps as well. > The lack of these in treeview is why people have turned to pure Tcl > alternatives even when treeview was available. If you want to look at > treeview as a multicolumn listbox, then it really fails in 2 areas - no > x scrolling and the inability to control stretch/shrink of columns. Joe > has said he likely won't have the time to address these before 8.5.0, > and thus I don't think it serves the core much to distract with the > treeview. > > Jeff > Jeff, While I generally agree with your criticism concerning the current development state of the treeview widget, I would have a quite serious problem if treeview wouldn't be integrated into the core. The reason is that in the tile-enabled version of Tablelist I make use of some treeview-related elements, like Treeheading.border and Treeheading.cell. Not having access to these elements would simply make it impossible for the Tablelist_tile package to work with Tk 8.5. Currently, Tablelist_tile is the only multi-column listbox with tile support, and a lot of people intend to keep using it with Tk 8.5. Also, your intention (decision?) to exclude treeview from the core doesn't take into account that there are quite a few people who already use treeview (in spite of its relatively early development state). After all, this wouldn't be the first widget in the core whose early versions are not yet quite satisfactory. With treectrl, the situation is different. This widget has always been a separate package, and from the programmer's point of view it makes no difference if it is merged into the core or not. Please, think about these arguments and don't exclude treeview from the core! Thanks, Csaba -- Csaba Nemethi http://www.nemethi.de mailto:csa...@t-... |
|
From: Jeff H. <je...@ac...> - 2006-11-22 21:38:41
|
Csaba Nemethi wrote: > Jeff Hobbs schrieb: > > Your points are in general correct, but overlook the direct remarks I > > made below. Those features are certainly required for a decent dir > > browser, but they are necessary for many other type of apps as well. > > The lack of these in treeview is why people have turned to pure Tcl > > alternatives even when treeview was available. If you want to look at > > treeview as a multicolumn listbox, then it really fails in 2 areas - no > > x scrolling and the inability to control stretch/shrink of columns. Joe > > has said he likely won't have the time to address these before 8.5.0, > > and thus I don't think it serves the core much to distract with the > > treeview. > While I generally agree with your criticism concerning the current > development state of the treeview widget, I would have a quite serious > problem if treeview wouldn't be integrated into the core. The reason is > that in the tile-enabled version of Tablelist I make use of some > treeview-related elements, like Treeheading.border and Treeheading.cell. While this is an interesting aspect, it is not strictly in favor of the treeview. It is perhaps possible to have the elements without the widget. > Also, your intention (decision?) to exclude treeview from the core > doesn't take into account that there are quite a few people who already > use treeview (in spite of its relatively early development state). > After all, this wouldn't be the first widget in the core whose early > versions are not yet quite satisfactory. Please identify these people. That is what I had hoped this discussion would do - flush out users of treeview to advocate that they are perfectly happy using it for X, Y and Z. On the contrary, I have received only more *negative* indicators. I am still open either way, but I have been pushed farther against in the last few days without anybody really advocating for on core widget value. Jeff |
|
From: Kevin W. <kw...@co...> - 2006-11-22 21:49:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Hobbs wrote: > Csaba Nemethi wrote: >> Jeff Hobbs schrieb: >>> Your points are in general correct, but overlook the direct remarks I >>> made below. Those features are certainly required for a decent dir >>> browser, but they are necessary for many other type of apps as well. >>> The lack of these in treeview is why people have turned to pure Tcl >>> alternatives even when treeview was available. If you want to look at >>> treeview as a multicolumn listbox, then it really fails in 2 areas - no >>> x scrolling and the inability to control stretch/shrink of columns. Joe >>> has said he likely won't have the time to address these before 8.5.0, >>> and thus I don't think it serves the core much to distract with the >>> treeview. > >> While I generally agree with your criticism concerning the current >> development state of the treeview widget, I would have a quite serious >> problem if treeview wouldn't be integrated into the core. The reason is >> that in the tile-enabled version of Tablelist I make use of some >> treeview-related elements, like Treeheading.border and Treeheading.cell. > > While this is an interesting aspect, it is not strictly in favor of the > treeview. It is perhaps possible to have the elements without the widget. > >> Also, your intention (decision?) to exclude treeview from the core >> doesn't take into account that there are quite a few people who already >> use treeview (in spite of its relatively early development state). >> After all, this wouldn't be the first widget in the core whose early >> versions are not yet quite satisfactory. > > Please identify these people. That is what I had hoped this discussion would > do - flush out users of treeview to advocate that they are perfectly happy > using it for X, Y and Z. On the contrary, I have received only more > *negative* indicators. I am still open either way, but I have been pushed > farther against in the last few days without anybody really advocating for on > core widget value. > > Jeff > I think Csaba's point is well-taken. I don't use the Tile treeview, but I do use tablelist_tile in all of my applications. If removing treeview altogether will break tablelist_tile, then that is an area of concern for me. It would certainly keep me from upgrading my apps to 8.5, unless Csaba found a way to implement the tablelist_tile bindings via other means. My guess is that there are probably more developers using tablelist_tile instead of treeview. - -- Kevin Walzer Code by Kevin http://www.codebykevin.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFZMXvEsLm8HXyq4sRAsx+AJ4/lNQ+dmJa2pNv1XIUgpBkXAko2ACdGgpk V2FNgYi2O4jbNNHqA+CC52c= =x7zV -----END PGP SIGNATURE----- |
|
From: Jeff H. <je...@ac...> - 2006-11-22 21:54:22
|
Kevin Walzer wrote: > Jeff Hobbs wrote: > > Csaba Nemethi wrote: > >> problem if treeview wouldn't be integrated into the core. The = reason is=20 > >> that in the tile-enabled version of Tablelist I make use of some=20 > >> treeview-related elements, like Treeheading.border and = Treeheading.cell. > >=20 > > While this is an interesting aspect, it is not strictly in favor of=20 > > the treeview. It is perhaps possible to have the elements without = the=20 > > widget. ... > I think Csaba's point is well-taken. well-taken or well-made? His point is compelling to me, as = tablelist_tile has always been on my mind as something people use over treeview. However, = if it only means defining from elements versus creation of a widget that = (arguably) very few people find useful, then that may be the way to go. > bindings via other means. My guess is that there are probably=20 > more developers using tablelist_tile instead of treeview. Mine as well, many more. However, I am fully open to users of treeview = making the case that the existing widget provides "good enough" functionality. Jeff |
|
From: Jeff H. <je...@ac...> - 2006-11-22 22:09:02
|
Jeff Hobbs wrote: > > bindings via other means. My guess is that there are probably > > more developers using tablelist_tile instead of treeview. >=20 > Mine as well, many more. However, I am fully open to users=20 > of treeview making the case that the existing widget provides=20 > "good enough" functionality. Let's add some more food for thought in that treeview is the largest = single widget by code size in tile - 2x larger than notebook and 3x larger than button. This all pales in comparison to the size of treectrl, and I = know that any tree will have some significant size. The point is that it needs to have some compelling case to go in. Does tablelist_tile's use of its theme elements justify it in itself? Are = there clear small use cases where the existing widget provides satisfactory functionality? People will ask "why was this added?" - what will the = answer be? All the other parts of tile excite me - it's a great body of work, = but this one widget (and to some extent ttk::dialog) give me pause. Jeff |
|
From: Kevin W. <kw...@co...> - 2006-11-22 22:17:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Hobbs wrote: > > The point is that it needs to have some compelling case to go in. Does > tablelist_tile's use of its theme elements justify it in itself? I think it does. > Are there clear small use cases where the existing widget provides satisfactory > functionality? I think tablelist_tile is a non-trivial use case. I don't have much use for treeview in itself. It doesn't look quite right on the Mac, which is my platform. I find BWidget's tree widget provides all the functionality I need from a tree. But tablelist, by itself, doesn't look native on the Mac: tablelist_tile is a *really* nice thing to have. Perhaps Csaba can add some insight into how difficult it would be to provide the tablelist_tile bindings without treeview. - -- Kevin Walzer Code by Kevin http://www.codebykevin.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFZMx0EsLm8HXyq4sRAjezAJ0UL+a/VPwXpmaxNIU+Y2P/vHNmwQCffo9+ VI9dwtyYMlRbjwGCnC36uO0= =STXp -----END PGP SIGNATURE----- |
|
From: Kevin W. <kw...@co...> - 2006-11-22 22:21:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Please identify these people. That is what I had hoped this discussion would > do - flush out users of treeview to advocate that they are perfectly happy > using it for X, Y and Z. O For what it's worth: I currently ship three shareware applications that make use of tablelist_tile. I have four more applications under development, and at least three of them will make use of tablelist_tile. I realize it's not a popularity contest, but tablelist_tile (and by extension treeview) is at the foundation of my software development business. Tktreectrl is simply too complex for my needs: tablelist_tile, by contrast, is perfect. Reverting to the standard tablelist widget would, most likely, impact the sales of my software, because Mac users are very picky about how their apps fit in with the platform's interface guidleines. With tablelist_tile, they do so very well. Standard tablelist, like standard Tk, doesn't, at least not on the Aqua platform. - -- Kevin Walzer Code by Kevin http://www.codebykevin.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFZM1dEsLm8HXyq4sRAu1TAJ9bhW1ADvuj49ItJ+uH1ch6ID6C9ACffLvS dwRxAFORTn880IQclwYNg48= =FAYR -----END PGP SIGNATURE----- |
|
From: Jeff H. <je...@ac...> - 2006-11-22 22:30:22
|
Kevin Walzer wrote: > > Please identify these people. That is what I had hoped this > > discussion would do - flush out users of treeview to advocate that > > they are perfectly happy using it for X, Y and Z. O > > For what it's worth: I currently ship three shareware > applications that make use of tablelist_tile. I have four > more applications under development, and at least three of > them will make use of tablelist_tile. I realize it's not a > popularity contest, but tablelist_tile (and by extension > treeview) is at the foundation of my software development > business. Tktreectrl is simply too complex for my needs: > tablelist_tile, by contrast, is perfect. As noted before, this is really a condemnation of treeview coupled with the point that tree elements need to be defined in Ttk. What you are really saying is that ttk::tablelist is what you want in the core. > Reverting to the standard tablelist widget would, most > likely, impact the sales of my software, because Mac users No, it would not. You would just still require tile in 8.5 (and it does work). Jeff |
|
From: Csaba N. <csa...@t-...> - 2006-11-22 22:52:12
|
Jeff Hobbs schrieb: > Csaba Nemethi wrote: > >> While I generally agree with your criticism concerning the current >> development state of the treeview widget, I would have a quite serious >> problem if treeview wouldn't be integrated into the core. The reason is >> that in the tile-enabled version of Tablelist I make use of some >> treeview-related elements, like Treeheading.border and Treeheading.cell. > > While this is an interesting aspect, it is not strictly in favor of the > treeview. It is perhaps possible to have the elements without the widget. > Well, AFAIK, these elements are implemented in the file treeview.c, which is pretty large (containing the whole treeview stuff). It is surely possible to provide these elements by keeping only the relevant parts of this file. Either way, *I really need these elements, or else Tablelist_tile will die*, which I (and many others) would greatly regret. >> Also, your intention (decision?) to exclude treeview from the core >> doesn't take into account that there are quite a few people who already >> use treeview (in spite of its relatively early development state). >> After all, this wouldn't be the first widget in the core whose early >> versions are not yet quite satisfactory. > > Please identify these people. That is what I had hoped this discussion would > do - flush out users of treeview to advocate that they are perfectly happy > using it for X, Y and Z. On the contrary, I have received only more > *negative* indicators. I am still open either way, but I have been pushed > farther against in the last few days without anybody really advocating for on > core widget value. > > Jeff > > By searching for "treeview* on the Wiki, you can find about half a dozen applications making use of treeview. But there are probably much more scripts based on this widget, and I am sure that their authors would be rather unhappy learning that these scripts will no longer work with Tk 8.5. Most of these people are probably no subscribers of this list, therefore I'm not sure this discussion is the right way to find out whether treeview should be merged into the core or not. The c.l.t. newsgroup would probably be more adequate for this purpose. Csaba (wanting to keep Tablelist_tile alive) -- Csaba Nemethi http://www.nemethi.de mailto:csa...@t-... |
|
From: Jeff H. <je...@ac...> - 2006-11-22 23:05:06
|
Csaba Nemethi wrote: > parts of this file. Either way, *I really need these elements, or = else=20 > Tablelist_tile will die*, which I (and many others) would greatly = regret. Again let me state that this is patently incorrect. What will happen is = that you would still require tile for 8.5. > By searching for "treeview* on the Wiki, you can find about half a = dozen=20 > applications making use of treeview. But there are probably much more = > scripts based on this widget, and I am sure that their authors would = be=20 > rather unhappy learning that these scripts will no longer work with Tk = 8.5. Again, they would work, still requiring tile for treeview (if we choose = not to include it in Ttk). A review of the wiki bits: * http://wiki.tcl.tk/13636 DaFT, uses treeview, had to add x scrolling themselves. * http://wiki.tcl.tk/15839 tkHelpBrowser, Kevin Walzer, represented = here. That's *it*. Please don't be distracted by the fact the BLT also has a treeview widget. The above evidence does /not/ help treeview's case. = ;) Jeff |
|
From: Kevin W. <kw...@co...> - 2006-11-22 23:19:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Hobbs wrote: > > A review of the wiki bits: > > * http://wiki.tcl.tk/13636 DaFT, uses treeview, had to add x scrolling > themselves. > > * http://wiki.tcl.tk/15839 tkHelpBrowser, Kevin Walzer, represented here. > Jeff, That's not quite right: PortAuthority: http://wiki.tcl.tk/14917 NameFind http://wiki.tcl.tk/16670 VuMan: (listed on http://wiki.tcl.tk/693) However, if I can still use tablelist_tile via package require tile, then I am fine with that. Question: how will the 'package require tile' mechanism work when tile is in the core? WIll it require me to build an older version of Tile against Tk 8.4? - --Kevin - -- Kevin Walzer Code by Kevin http://www.codebykevin.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFZNrpEsLm8HXyq4sRAqtUAJ9pRDqUjFHKfb8i8ANUAf0uOpf80ACfTT/S J8rOIq90TMcwU2BVJ2gj77Q= =53LA -----END PGP SIGNATURE----- |
|
From: Jeff H. <je...@ac...> - 2006-11-22 23:31:17
|
Kevin Walzer wrote: > Jeff Hobbs wrote: > > A review of the wiki bits: > > > > * http://wiki.tcl.tk/13636 DaFT, uses treeview, had to add x scrolling > > themselves. > > > > * http://wiki.tcl.tk/15839 tkHelpBrowser, Kevin Walzer, represented > > here. > > That's not quite right: > > PortAuthority: http://wiki.tcl.tk/14917 > NameFind http://wiki.tcl.tk/16670 > VuMan: (listed on http://wiki.tcl.tk/693) OK, these are more of your projects, so you are still covered as represented. Do you list these because you use treeview or tablelist (or both)? It may well be possible that many other apps are using treeview that simple make no mention of it. A visual overview of the "Applications using Tile" page indicates that Grimoire uses it, but not the other apps listed there. > However, if I can still use tablelist_tile via package > require tile, then I am fine with that. Question: how will > the 'package require tile' mechanism work when tile is in the > core? WIll it require me to build an older version of Tile > against Tk 8.4? The head of tile is package require'able into the head of Tk. That should be maintained. Some underlying bits (at the C level) may change to prevent name conflicts. Jeff |
|
From: Tim B. <tre...@ho...> - 2006-11-22 23:39:50
|
Regarding Treeitem.indicator et al, it is already the case that they are defined (sometimes) outside of the treeview file. The native WinXP and MacOSX themes define the indicator (obviously or you wouldn't see them draw natively on those platforms). The "alt" them also defines Treeitem.indicator. It is merely a matter of defining these elements in the other X11-ish styles as well. Probably the "default" theme is the best place so they are inherited by any style which doesn't define them. PS: I'm on the mailing list so no need to 'CC' me thx. -- Tim Baker |
|
From: Eckhard L. <ec...@we...> - 2006-11-25 21:24:11
|
Jeff Hobbs schrieb: > >> Also, your intention (decision?) to exclude treeview from the core >> doesn't take into account that there are quite a few people who already >> use treeview (in spite of its relatively early development state). >> After all, this wouldn't be the first widget in the core whose early >> versions are not yet quite satisfactory. >> > > Please identify these people. Jeff, actually I am using treeview quite a lot for the Tloona IDE (www.tloona.tk) and underlying "Tmw" megawidgets (which are part of Tloona only). X scroll would be fine, but in general I am happy that it is so simple to use compared to treectrl. I would have a real problem if treeview was not included in the final version of Tk. Also I think that the real way is somewhere in between treectrl and treeview. The easy handling of treeview, together with some more of treectrl's features would be fine. But not all of treectrl's features... what I'd appreciate is the functionality of treeview plus: - putting arbitrary windows/widgets in tree columns, like in tktable and treectrl - aligning text/labels/widgets in treeview (-sticky) - have editable text in tree columns I would be very happy with that, it's all I can imagine as necessary for a tree widget in my (developer) life ;-). Eckhard |
|
From: Tim B. <tre...@ho...> - 2006-11-25 22:30:07
|
Eckhard Lehmann wrote: >Jeff, > >actually I am using treeview quite a lot for the Tloona IDE >(www.tloona.tk) and underlying "Tmw" megawidgets (which are part of >Tloona only). X scroll would be fine, but in general I am happy that >it is so simple to use compared to treectrl. I would have a real >problem if treeview was not included in the final version of Tk. > >Also I think that the real way is somewhere in between treectrl and >treeview. The easy handling of treeview, together with some more of >treectrl's features would be fine. But not all of treectrl's >features... what I'd appreciate is the functionality of treeview >plus: >- putting arbitrary windows/widgets in tree columns, like in tktable >and treectrl >- aligning text/labels/widgets in treeview (-sticky) >- have editable text in tree columns > >I would be very happy with that, it's all I can imagine as necessary >for a tree widget in my (developer) life ;-). > > >Eckhard TreeCtrl was never meant to be a front-end widget, it was meant to be a back-end that could be used to create front-end widgets. People have been using the Canvas for years as a back-end for all sorts of listboxes and tree widgets. More recently, Tablelist can be seen using the Text widget as a back-end for a multi-column listbox. Neither the Canvas nor the Text widget is particularly suitable for this purpose, especially when a list grows large. How much easier it would be to implement a BWidget or Tile tree or Tablelist listbox on top of TreeCtrl! That's what TreeCtrl aims for, not to be a replacement for all those well-worn widgets but to make it easier to implement them in the first place. -- Tim Baker |
|
From: Eckhard L. <ec...@we...> - 2006-11-26 12:01:02
|
Tim Baker schrieb: > > TreeCtrl was never meant to be a front-end widget, it was meant to be > a back-end that could be used to create front-end widgets. People have > been using the Canvas for years as a back-end for all sorts of listboxes > and tree widgets. More recently, Tablelist can be seen using the Text > widget as a back-end for a multi-column listbox. Neither the Canvas nor > the Text widget is particularly suitable for this purpose, especially > when a list grows large. How much easier it would be to implement a > BWidget or Tile tree or Tablelist listbox on top of TreeCtrl! That's what > TreeCtrl aims for, not to be a replacement for all those well-worn > widgets but to make it easier to implement them in the first place. > You mean that treeview should be implemented on top of treectrl, as well as any table like widget? Would be good to have that as an example somewhere... If it is possible, that's fine. And if this implementation would have the same or similar interface as treeview, even better. Eckhard |
|
From: Jeff H. <je...@ac...> - 2006-11-28 01:54:54
Attachments:
treelist.tcl
|
Eckhard Lehmann wrote: > Tim Baker schrieb: > > TreeCtrl was never meant to be a front-end widget, it was meant to = be=20 > > a back-end that could be used to create front-end widgets. People = have=20 > > been using the Canvas for years as a back-end for all sorts of=20 > > listboxes and tree widgets. More recently, Tablelist can be seen = using=20 > > the Text widget as a back-end for a multi-column listbox. Neither = the=20 ... > You mean that treeview should be implemented on top of treectrl, as = well=20 > as any table like widget? Yes, I mentioned the same before. I had reservations in that treectrl = was memory hungry, but Tim did address that in part with treectrl 2.2. = Still, it may be more efficient to go with a lightweight solution like treeview. Unfortunately I don't have the time to write the requisite snidget, but = from reviewing the treeview docs, and knowing treectrl pretty well, treectrl = can do 100% of what treeview requires. Thus a snidget is possible for someone enterprising enough to try. I've even attached the right template to = start from. ;) Of course, you would probably design the treeview differently, if you = knew you planned to build it on treectrl. That was part of the hesitation to = include it in 8.5. Jeff |
|
From: Tim B. <tre...@ho...> - 2006-11-28 04:18:25
Attachments:
treectrl_treeview.tcl
|
>Eckhard Lehmann wrote: >> Tim Baker schrieb: >>> TreeCtrl was never meant to be a front-end widget, it was meant to be >>> a back-end that could be used to create front-end widgets. People have >>> been using the Canvas for years as a back-end for all sorts of >>> listboxes and tree widgets. More recently, Tablelist can be seen using >>> the Text widget as a back-end for a multi-column listbox. Neither the >... >> You mean that treeview should be implemented on top of treectrl, as well >> as any table like widget? > Yes, I mentioned the same before. I had reservations in that treectrl was > memory hungry, but Tim did address that in part with treectrl 2.2. Still, > it > may be more efficient to go with a lightweight solution like treeview. > Unfortunately I don't have the time to write the requisite snidget, but > from > reviewing the treeview docs, and knowing treectrl pretty well, treectrl > can do > 100% of what treeview requires. Thus a snidget is possible for someone > enterprising enough to try. I've even attached the right template to > start > from. ;) > Of course, you would probably design the treeview differently, if you knew > you > planned to build it on treectrl. That was part of the hesitation to > include > it in 8.5. > Jeff I actually did this. It isn't very robust in terms of error checking and doesn't use the tile fonts among other things. But api-wise it can be used in the tile demo.tcl and dirbrowser.tcl. Just edit the pathname at the bottom of the attached file to see it in action. Requires perhaps the latest versions of snit, tile and treectrl. -- Tim Baker |
|
From: Will D. <Wil...@jp...> - 2006-11-22 21:24:46
|
Jeff, This is exactly my point--there are uses for a tree widget that do *not* resemble a rich multicolumn listbox. Will On Nov 22, 2006, at 8:42 AM, Jeff Hobbs wrote: > Will, > > Your points are in general correct, but overlook the direct remarks I > made below. Those features are certainly required for a decent dir > browser, but they are necessary for many other type of apps as well. > The lack of these in treeview is why people have turned to pure Tcl > alternatives even when treeview was available. If you want to look at > treeview as a multicolumn listbox, then it really fails in 2 areas - no > x scrolling and the inability to control stretch/shrink of columns. > Joe > has said he likely won't have the time to address these before 8.5.0, > and thus I don't think it serves the core much to distract with the > treeview. > > Jeff > > Will Duquette wrote: >> Jeff, >> >> You keep talking about directory browsing, which is an application >> for which a tree is useful but which involves considerably more than >> basic tree behavior. treectrl supports this, and treeview doesn't. >> >> I think the basic problem here is that although both widgets have >> "tree" in their name, treectrl *isn't* a "tree" widget. You can use >> it for that; but it's really something more powerful, and perhaps >> should >> have a name that indicates that. >> >> Frankly, I can see a place in Tk/Ttk for both widgets. A simple one, >> akin to the standard Tk listbox, and a complex but vastly more >> powerful >> one. >> >> Will >> >> On Nov 21, 2006, at 4:02 PM, Jeff Hobbs wrote: >> >>> Tim Baker wrote: >>>> Jeff Hobbs wrote: >>>>> 2.2). However, if I only needed what a "simpler" treeview would >>>>> provide, >>>>> and >>>>> it provided it with a memory size of ~20MB for the same app ... >>>>> does >>>>> that >>>>> not justify a simpler, dedicated widget? >>>>> >>>>> Therein lies the real question - if we strongly feel that a simple >>> dedicated >>>>> and mega configurable tree widgets (2 separate) are both valuable, >>>>> let's >>>>> get treeview in 8.5, and treectrl in 8.6. >>>> >>>> Is it only the [style] and [element] commands that blows >>>> treectrl out of the "simple" space into "mega-configurable"? >>>> The high memory requirements are mostly a result of styles >>>> and elements. Whenever people comment that treectrl >>>> is difficult to use I start brainstorming alternate APIs. It >>>> always comes down to a question of how much control over the >>>> appearance of items is desired. >>> >>> Therein does lie the question. To be honest, I have very little >>> exposure to >>> the treeview widget, whereas I have done quite a bit with treectrl. >>> I >>> have >>> some comfort that ActiveState's use of treectrl has stressed it to >>> find weak >>> points (and resolve them for the most part). >>> >>> I don't know much about treeview's track record. I do know that the >>> little >>> bits I've seen always had /something/ wrong with them. The >>> demos/dirbrowser.tcl doesn't scroll right on Windows (adds too much >>> space at >>> the end), doesn't seem to handle the +/- stuff right, the headers >>> have >>> several >>> issues ... Anecdotally, for those who have had treeview and treectrl >>> available to them, where treectrl was too complicated to master, they >>> more >>> often turned to BWidget's tree (or tablelist if appropriate) than use >>> treeview >>> due to its lack of features. >>> >>> I will deconstruct the treeview "oversimplicity" from the dir browser >>> perspective, since I have done directory views with treectrl. >>> >>> * The handling of the sort arrow is a built-in feature in treectrl. >>> In >>> treeview (like tktable), you would have to manage the same yourself >>> with the >>> -image stuff (which can only be placed left of the label). >>> >>> * The columns - how do you specify which one has weight? Resize and >>> shrink >>> behavior? This is all possible in treectrl, but doesn't appear to >>> be in >>> treeview. >>> >>> * Is it possible with treeview to give a full single column a >>> background >>> without tagging each item (as one would do to indicate the current >>> sort >>> column)? >>> >>> * No x scrolling in treeview? >>> >>> * Auto-ellipsing, or other detection on truncation for treeview? >>> >>> * They do both have column and element visibility control. >>> >>> * Any row/column spanning in treeview? >>> >>> Except for the last one, the rest would all be desirable in the most >>> generic >>> of directory browsers. While it is certainly possible to address the >>> above >>> issues, is there time to do it? What about taking that time and >>> working on >>> ttk::dialog, ttk::toplevel, ttk::menu, etc? >>> >>> Jeff > > > ----------------------------------------------------------------------- > -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Tktable-tile-dev mailing list > Tkt...@li... > https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev > > ------------------------------------------------------------------------ Will Duquette, JPL | Wil...@jp... But I speak only | http://eis.jpl.nasa.gov/~will (JPL Use Only) for myself. | It's amazing what you can do with the right tools. |
|
From: Jeff H. <je...@ac...> - 2006-11-22 21:32:08
|
Will Duquette wrote: > This is exactly my point--there are uses for a tree widget > that do *not* resemble a rich multicolumn listbox. Like? Jeff |
|
From: Donal K. F. <don...@ma...> - 2006-11-23 09:26:16
|
Jeff Hobbs wrote: > Will Duquette wrote: >> This is exactly my point--there are uses for a tree widget >> that do *not* resemble a rich multicolumn listbox. > Like? An example is a document tree browser (e.g. the Contents tree that Windows help documentation browser presents). Each node in the tree is large enough that browsing it in a multi-column listbox would suck; I'd hate to have to horizontal-scroll through a whole HTML file. :-) I would imagine that any other time people have a tree of semi-structured information, the bolting-on of a multi-column listbox to a tree would count as a spare wheel too. (Which isn't to say that it isn't useful for a tree of structured information, of course.) BTW, if you have a tree and a table^W multi-column listbox, surely you'd want to be able to x-scroll each part independently? Otherwise you'd lose track of where you are when you're scanning across a wide table, or there would be trouble with tree nodes whose names are too wide forcing the first column to be very wide just so that you could see the end of the node labels... (Hmm, I'm not explaining that too well.) Donal. |
