tktable-tile-dev Mailing List for TkTable / Tile / Vu (Page 8)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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

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.

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

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

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.

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

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 

Bryan Oakley wrote:
> Jeff Hobbs wrote:
> > Also, the fact that OO got bumped to 8.6 also threw some ideas I was 
> > hoping for 8.5 out with it (in terms of easier megawidgets based on 
> > core widgets).
> 
> Hmmm. I somehow missed that announcement. Out of curiosity, when was 
> that decided?

You will have to go over the tcl-core archives to get the full details, but I
basically stepped into a heated discussion to note that we were too close to
beta (feature freeze) to move forward with an as-yet-untested OO framework.

It is an unfortunate decision to lose oo across the board, but it does hit Tk
especially hard.  Tk could really leverage oo for a megawidget framework.
Snit provide 90% of the necessary bits, but that remaining 10% is important,
and really requires some better core support for "objects".

Jeff

Jeff Hobbs wrote:
> Also, the fact that OO got bumped to 8.6 also threw some ideas I was hoping
> for 8.5 out with it (in terms of easier megawidgets based on core widgets).

Hmmm. I somehow missed that announcement. Out of curiosity, when was 
that decided?

Brett Schwarz wrote:
> I like the idea of waiting for 8.6 to get a good solution for=20
> a tree widget in the core (whether that's an enhanced=20
> treeview or a wrangled up tktreectrl). Even though I would=20
> have loved to see it part of 8.5, I'd rather wait for a good=20
> 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.

(BTW Tim - I had to modify the configure.ac to kick treectrl to 2.2 - =
any
reason not to commit that?)

Also, the fact that OO got bumped to 8.6 also threw some ideas I was =
hoping
for 8.5 out with it (in terms of easier megawidgets based on core =
widgets).

Jeff

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 tktreect=
rl). Even though I would have loved to see it part of 8.5, I'd rather wait =
for a good and solid solution.=0A=0A=0A=0A----- Original Message ----=0AFro=
m: Jeff Hobbs <je...@ac...>=0ATo: Larry McVoy <lm...@bi...>; =
Joe English <jen...@fl...>=0ACc: tkt...@li...=
ge.net; Tim Baker <tre...@ho...>=0ASent: Monday, November 20, 2006 =
11:38:07 AM=0ASubject: Re: [Tile-dev] Tile compatibility policy and the cor=
e merge=0A=0ALarry McVoy wrote:=0A> > First: the treeview widget needs to c=
ome back.  People are actually =0A> > using this widget, and the only alter=
native I can think of is for them =0A> > to switch to TkTreeCtrl.  Although=
 TkTreeCtrl can certainly do all the =0A> > things that ttk::treeview can (=
and much, much more!), it's not that =0A> > easy to use; and since "ease of=
 use" is the primary, overriding design =0A> > goal of the ttk::treeview wi=
dget, I don't think this will be work =0A> > upgrade strategy.=0A> =0A> Has=
 anyone considered the idea of wrapping the treeview =0A> widget API around=
 TkTreeCtrl?  From what I can see, the =0A> advantage of treeview is that i=
t is pretty easy to use and =0A> the advantage of TkTreeCtrl is that it is =
powerful but =0A> complex.  Seems like a simplistic API that offers a "kind=
er =0A> and gentler" introduction to TkTreeCtrl is perhaps a more =0A> stra=
tegic approach than maintaining two code bases.=0A=0AI have considered this=
, but there is simply not enough time to definitively=0Asay which is the be=
st way to go for 8.5.  treeview has some "deficiencies",=0Abut that may jus=
t be my view of greater expectations from tree widgets.  I=0Aknow that Joe =
has done a good deal of work on this, and I really intend no=0Apersonal aff=
ront.  I want to look at it from an objective core future=0Aperspective.=0A=
=0AI use treectrl a lot, but there certainly is not enough time to wrangle =
it=0Ainto "core status" for 8.5.  Furthermore, Tim is continuing to work on=
 it.=0AI'd like us to consider this again for 8.6 though (along with tktabl=
e).  One=0Aof the current issues with treectrl is that it is a memory pig (=
notably more=0Athan I expect should be necessary for some views), but I exp=
ect some API=0Achanges (possibly compatible) would be in order as well.=0A=
=0Atreectrl also does a ton more than a simple treeview requires.  Useful f=
or=0Asome apps, but a multi-column list is really important by itself.  tre=
eview is=0Anice, but it lacks functionality that others may find useful hav=
ing come to=0Aexpect them in packages like tablelist and bwidget's tree.  t=
reeview's=0Ainclusion in the core will hamper any rapid improvements (that =
of course=0Adepends on how objectionable others will be to feature improvem=
ents in=0Apatchlevel releases).=0A=0AAs you may see, I'm currently still si=
tting on the fence on this one.=0A=0AJeff=0A=0A=0A-------------------------=
------------------------------------------------=0ATake Surveys. Earn Cash.=
 Influence the Future of IT=0AJoin SourceForge.net's Techsay panel and you'=
ll get the chance to share your=0Aopinions on IT & business topics through =
brief surveys - and earn cash=0Ahttp://www.techsay.com/default.php?page=3Dj=
oin.php&p=3Dsourceforge&CID=3DDEVDEV=0A____________________________________=
___________=0ATktable-tile-dev mailing lis...@li...=
forge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/tktable-tile-dev=
=0A=0A=0A=0A=0A

Donal K. Fellows wrote:
> Jeff Hobbs wrote:
> > (that of course
> > depends on how objectionable others will be to feature improvements in 
> > patchlevel releases).
> 
> If we put some large warnings in the documentation, I think 
> we can get away with it. If we can simultaneously arrange for 
> at least basic common usage (i.e. for people who don't tweak 
> stuff) to remain the same, so much the better.

Also note that we should allow ourselves to take advatange of the fact that
8.5+ will be require-able by specific patchlevel (yeah!).

Jeff

Jeff Hobbs wrote:
> (that of course
> depends on how objectionable others will be to feature improvements in
> patchlevel releases).

If we put some large warnings in the documentation, I think we can get
away with it. If we can simultaneously arrange for at least basic common
usage (i.e. for people who don't tweak stuff) to remain the same, so
much the better.

Donal (I can remember the Tk 8.4 panedwindow had some horrible bugs that
        made it unusable until quite far into the 8.4 release cycle, so a
        new widget not being 100% baked wouldn't be unprecedented.)

Tim Baker wrote:
> > From: "Jeff Hobbs"
> > I use treectrl a lot, but there certainly is not enough time to 
> > wrangle it into "core status" for 8.5.  Furthermore, Tim is continuing 
> > to work on it. I'd like us to consider this again for 8.6 though 
> > (along with tktable). One of the current issues with treectrl is that 
> > it is a memory pig (notably more
> > than I expect should be necessary for some views), but I expect some API
> > changes (possibly compatible) would be in order as well.
> 
> I've managed to get memory usage under control a bit. In the 
> "Random 500" demo with "set RandomN 15000" wish84.exe requires:
> 
>     2.1.1        47,240 K
>     2.2           21,424 K
> 
> Whoa. I think those are both non-debug versions.

That is indeed an improvement.  More structure sharing?  In any case, I found
that using 60M for 6000 items to be a bit much in my app.  I suspect it also
led to some amount of slowdown for all the mem mgmt.  However, I'm not
currently able to build treectrl from CVS - some transition from themeData
in/out of the TreeCtrl structure?

Jeff

> From: "Jeff Hobbs"
> I use treectrl a lot, but there certainly is not enough time to wrangle it
> into "core status" for 8.5.  Furthermore, Tim is continuing to work on it.
> I'd like us to consider this again for 8.6 though (along with tktable). 
> One
> of the current issues with treectrl is that it is a memory pig (notably 
> more
> than I expect should be necessary for some views), but I expect some API
> changes (possibly compatible) would be in order as well.

I've managed to get memory usage under control a bit. In the "Random 500"
demo with "set RandomN 15000" wish84.exe requires:

    2.1.1        47,240 K
    2.2           21,424 K

Whoa. I think those are both non-debug versions.

-- Tim Baker 

Larry McVoy wrote:
> > First: the treeview widget needs to come back.  People are actually=20
> > using this widget, and the only alternative I can think of is for =
them=20
> > to switch to TkTreeCtrl.  Although TkTreeCtrl can certainly do all =
the=20
> > things that ttk::treeview can (and much, much more!), it's not that=20
> > easy to use; and since "ease of use" is the primary, overriding =
design=20
> > goal of the ttk::treeview widget, I don't think this will be work=20
> > upgrade strategy.
>=20
> Has anyone considered the idea of wrapping the treeview=20
> widget API around TkTreeCtrl?  From what I can see, the=20
> advantage of treeview is that it is pretty easy to use and=20
> the advantage of TkTreeCtrl is that it is powerful but=20
> complex.  Seems like a simplistic API that offers a "kinder=20
> and gentler" introduction to TkTreeCtrl is perhaps a more=20
> strategic approach than maintaining two code bases.

I have considered this, but there is simply not enough time to =
definitively
say which is the best way to go for 8.5.  treeview has some =
"deficiencies",
but that may just be my view of greater expectations from tree widgets.  =
I
know that Joe has done a good deal of work on this, and I really intend =
no
personal affront.  I want to look at it from an objective core future
perspective.

I use treectrl a lot, but there certainly is not enough time to wrangle =
it
into "core status" for 8.5.  Furthermore, Tim is continuing to work on =
it.
I'd like us to consider this again for 8.6 though (along with tktable).  =
One
of the current issues with treectrl is that it is a memory pig (notably =
more
than I expect should be necessary for some views), but I expect some API
changes (possibly compatible) would be in order as well.

treectrl also does a ton more than a simple treeview requires.  Useful =
for
some apps, but a multi-column list is really important by itself.  =
treeview is
nice, but it lacks functionality that others may find useful having come =
to
expect them in packages like tablelist and bwidget's tree.  treeview's
inclusion in the core will hamper any rapid improvements (that of course
depends on how objectionable others will be to feature improvements in
patchlevel releases).

As you may see, I'm currently still sitting on the fence on this one.

Jeff

> Other changes: tile::availableThemes -> ttk::themes,
> and tile::setTheme -> ttk::setTheme.  Everything else
> in the tile::* namespace is gone (none of that was
> public anyway, though).
>=20
> At the moment, in Tk CVS HEAD, calling "package require tile"=20
> in an 8.5a6 interp will break badly.  This needs to be fixed=20
> before 8.5 beta.
>=20
> For themes and custom widgets, there might be more changes.

It seems that the current major blocker is that the ttk::theme::default
versions differ (and an error is thrown on the different version =
provide), and
then that the named font TkClassicDefaultFont already exists.

Putting a catch around those 2 statements allows for tile to be package
required into 8.5.  I don't see any reason not to commit those changes =
...

Jeff

> First: the treeview widget needs to come back.  People are
> actually using this widget, and the only alternative I can think
> of is for them to switch to TkTreeCtrl.  Although TkTreeCtrl can
> certainly do all the things that ttk::treeview can (and much,
> much more!), it's not that easy to use; and since "ease of use"
> is the primary, overriding design goal of the ttk::treeview
> widget, I don't think this will be work upgrade strategy.

Has anyone considered the idea of wrapping the treeview widget API
around TkTreeCtrl?  From what I can see, the advantage of treeview
is that it is pretty easy to use and the advantage of TkTreeCtrl
is that it is powerful but complex.  Seems like a simplistic API
that offers a "kinder and gentler" introduction to TkTreeCtrl is
perhaps a more strategic approach than maintaining two code bases.

Comments?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Kevin Walzer wrote:
>
> I'm not clear on what changes will need to be made to my code when Tile
> goes into the core. Currently I use "package require tile" and the ttk::
> namespace to set up my widgets. What will I need to do differently when
> I start using Tk 8.5?

For application code, hopefully very little :-)

As mentioned earlier, [ttk::paned] has been renamed
to [ttk::panedwindow].  If you're using 0.7.8 you can
change that right now, since [ttk::panedwindow] is
available as a forward-compatibility alias.

[style] has been renamed to [ttk::style].  Tile 0.7.8
doesn't have a forward-compat alias for this one since
I didn't know this was going to happen.

The ttk::treeview widget might not be there.

Other changes: tile::availableThemes -> ttk::themes,
and tile::setTheme -> ttk::setTheme.  Everything else
in the tile::* namespace is gone (none of that was
public anyway, though).

At the moment, in Tk CVS HEAD, calling "package require tile"
in an 8.5a6 interp will break badly.  This needs to be fixed
before 8.5 beta.

For themes and custom widgets, there might be more changes.

--Joe English

  jen...@fl...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joe English wrote:
> 
> When making incompatible changes to the Tile public API,
> I've been trying to follow a policy where the old and new
> syntaxes are both supported for at least one release cycle,
> then removing the old syntax at a later time.  This is to
> avoid the need for "flag day" conversions, where users have
> to upgrade all the programs that use Tile as soon as they
> upgrade Tile itself.
> 
> As it stands right now in Tk CVS HEAD, switching from
> Tk<=8.5a5+tile to Tk>=8.5a6 will require a flag day conversion.
> So the top priority for Tile 0.8.0 is to act as a transitional
> release: it should support the Tile 0.7.X interface as well
> as the ttk::* interface provided by the core.  That way
> users who wish to do so can upgrade in two easier stages
> instead of one hard one.
> 

I'm not clear on what changes will need to be made to my code when Tile
goes into the core. Currently I use "package require tile" and the ttk::
namespace to set up my widgets. What will I need to do differently when
I start using Tk 8.5?

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

iD8DBQFFX3lvEsLm8HXyq4sRAtA5AJ9Yi22xyoo3dDwRPkb0JAXc6J2EPQCeI5sm
68GZfu/uTCRZ42Y06Utm/f4=
=ncWi
-----END PGP SIGNATURE-----

Brett Schwarz wrote:

> So, I'm not following 100%. Are you saying when Tile goes into the core,
> we will lose the treeview widget?

Jeff added it to Tk CVS HEAD late last month, and yes,
the treeview widget is disabled by default.  There's
a configure-time option to bring it back; I don't know
what the long-term intentions are.

I'd prefer to have it included.

--Joe English

  jen...@fl...

So, I'm not following 100%. Are you saying when Tile goes into the core, we=
 will lose the treeview widget?=0A=0AThanks,=0A =0A--brett=0A=0A----- Origi=
nal Message ----=0AFrom: Joe English <jen...@fl...>=0ATo: tktable=
-til...@li...=0ASent: Saturday, November 18, 2006 12:18:2=
9 PM=0ASubject: [Tile-dev] Tile compatibility policy and the core merge=0A=
=0A=0A=0AWhen making incompatible changes to the Tile public API,=0AI've be=
en trying to follow a policy where the old and new=0Asyntaxes are both supp=
orted for at least one release cycle,=0Athen removing the old syntax at a l=
ater time.  This is to=0Aavoid the need for "flag day" conversions, where u=
sers have=0Ato upgrade all the programs that use Tile as soon as they=0Aupg=
rade Tile itself.=0A=0AAs it stands right now in Tk CVS HEAD, switching fro=
m=0ATk<=3D8.5a5+tile to Tk>=3D8.5a6 will require a flag day conversion.=0AS=
o the top priority for Tile 0.8.0 is to act as a transitional=0Arelease: it=
 should support the Tile 0.7.X interface as well=0Aas the ttk::* interface =
provided by the core.  That way=0Ausers who wish to do so can upgrade in tw=
o easier stages=0Ainstead of one hard one.=0A=0ATo make this work, the core=
 API will need a couple changes=0Aas well.=0A=0AFirst: the treeview widget =
needs to come back.  People are=0Aactually using this widget, and the only =
alternative I can think=0Aof is for them to switch to TkTreeCtrl.  Although=
 TkTreeCtrl can=0Acertainly do all the things that ttk::treeview can (and m=
uch,=0Amuch more!), it's not that easy to use; and since "ease of use"=0Ais=
 the primary, overriding design goal of the ttk::treeview=0Awidget, I don't=
 think this will be work upgrade strategy.=0A=0A(Jeff was talking about dro=
pping ttk::dialog, too.  That would=0Abe OK, since the implementation is al=
l in Tcl and can be=0Adistributed separately, but ttk::treeview can't be.)=
=0A=0ANext: Ttk_Init() in the core needs to [package provide $something].=
=0ARight now, if you load the tile package into an 8.5a6 core,=0Aall heck b=
reaks loose, and I don't know how to fix this yet.=0ASo existing code that =
says [package require tile] is going=0Ato suffer catastrophic failure unles=
s 8.5a6+ can make this=0Ainto a no-op, either by declaring "tile 0.8.0" alr=
eady=0Aprovided or by registering a do-nothing "ifneeded" script.=0A=0AThe =
stubs mechanism (needed for third-party themes like TileQT)=0Aalso uses the=
 package database, which is another reason for=0Athe core to [package provi=
de $something].  I can find a workaround=0Afor this if necessary, though.=
=0A=0AAnd on the subject of third-party themes: Tk 8.5 is definitely=0Agoin=
g to require a flag day conversion for them.  This isn't=0Aas big a deal --=
 there aren't as many themes as there are=0Aapplications using Tile, the ch=
anges required are minor and=0Amostly mechanical, and a flag day for themes=
 was on the=0ATile 0.8.X roadmap anyway.=0A=0AIt doesn't look like I'll be =
able to get the theme overhaul=0Adone in time for the December core release=
, so third party=0Atheme developers should expect two flag days.  Sorry abo=
ut=0Athat; the release schedules just aren't lined up right.=0A=0A=0A--Joe =
English=0A=0A  jen...@fl...=0A=0A--------------------------------=
-----------------------------------------=0ATake Surveys. Earn Cash. Influe=
nce the Future of IT=0AJoin SourceForge.net's Techsay panel and you'll get =
the chance to share your=0Aopinions on IT & business topics through brief s=
urveys - and earn cash=0Ahttp://www.techsay.com/default.php?page=3Djoin.php=
&p=3Dsourceforge&CID=3DDEVDEV=0A___________________________________________=
____=0ATktable-tile-dev mailing lis...@li....n=
et=0Ahttps://lists.sourceforge.net/lists/listinfo/tktable-tile-dev=0A=0A=0A=
=0A=0A

When making incompatible changes to the Tile public API,
I've been trying to follow a policy where the old and new
syntaxes are both supported for at least one release cycle,
then removing the old syntax at a later time.  This is to
avoid the need for "flag day" conversions, where users have
to upgrade all the programs that use Tile as soon as they
upgrade Tile itself.

As it stands right now in Tk CVS HEAD, switching from
Tk<=8.5a5+tile to Tk>=8.5a6 will require a flag day conversion.
So the top priority for Tile 0.8.0 is to act as a transitional
release: it should support the Tile 0.7.X interface as well
as the ttk::* interface provided by the core.  That way
users who wish to do so can upgrade in two easier stages
instead of one hard one.

To make this work, the core API will need a couple changes
as well.

First: the treeview widget needs to come back.  People are
actually using this widget, and the only alternative I can think
of is for them to switch to TkTreeCtrl.  Although TkTreeCtrl can
certainly do all the things that ttk::treeview can (and much,
much more!), it's not that easy to use; and since "ease of use"
is the primary, overriding design goal of the ttk::treeview
widget, I don't think this will be work upgrade strategy.

(Jeff was talking about dropping ttk::dialog, too.  That would
be OK, since the implementation is all in Tcl and can be
distributed separately, but ttk::treeview can't be.)

Next: Ttk_Init() in the core needs to [package provide $something].
Right now, if you load the tile package into an 8.5a6 core,
all heck breaks loose, and I don't know how to fix this yet.
So existing code that says [package require tile] is going
to suffer catastrophic failure unless 8.5a6+ can make this
into a no-op, either by declaring "tile 0.8.0" already
provided or by registering a do-nothing "ifneeded" script.

The stubs mechanism (needed for third-party themes like TileQT)
also uses the package database, which is another reason for
the core to [package provide $something].  I can find a workaround
for this if necessary, though.

And on the subject of third-party themes: Tk 8.5 is definitely
going to require a flag day conversion for them.  This isn't
as big a deal -- there aren't as many themes as there are
applications using Tile, the changes required are minor and
mostly mechanical, and a flag day for themes was on the
Tile 0.8.X roadmap anyway.

It doesn't look like I'll be able to get the theme overhaul
done in time for the December core release, so third party
theme developers should expect two flag days.  Sorry about
that; the release schedules just aren't lined up right.

--Joe English

  jen...@fl...

Georgios Petasis wrote:

> I have a small problem with the label frame widget. From what I
> understand, this widget
> has 2 elements: a border & a text element.
>
> Right now, tileqt defines an element only for the border. No element is
> defined for the text (as I will have to do text drawing with Qt). What I
> cannot understand, is why the default text element of the labelframe
> widget does not use the "background" element for drawing the text
> background.
>
> What I observe with the tileqt theme, is that the label widget is always
> drawn with the correct background, as it uses the background element
> tileqt provides. But the labelframe's text does not do the same:
> If I use the "tile::theme::tileqt::setPalette -background white" command
> for changing the palette of Qt, this affects all widgets (including the
> label widget where tileqt does not define any elements) but not the
> labelframe widget. Why is that?
> How can I fix this?

Some background:

The built-in "text" element only draws the text, it doesn't
erase the background first.  If this element is used in
a conventional Labelframe layout, the labelframe's border
will be drawn through the middle of the text.  Tile defines
a specialized version of the element, "Labelframe.text", that
fills the element's parcel with the -background color before
drawing the text.

What's probably happening in TileQt: it looks like
[tile::theme::tileqt::setPalette] only changes Qt's
system colors, it doesn't update Tile's style settings.
So the Labelframe.text widget picks up the original
setting for -background.  To fix this, it should suffice
to just use:

    style configure TLabelframe -background [currentThemeColour -background]

after [tile::theme::tileqt::setPalette].

--Joe English

  jen...@fl...

Tim Baker wrote:

> I've been looking into a tile version of treectrl. Using treeview as
> a guide, I end up needing the following things exported:
>

Many of those are scheduled to be added to the stubs table
sometime later, but not all.

The Tile package can be broken up into roughly three subsystems:
the part that deals with defining elements and styles,
the part that deals with using elements and styles, and
the part that deals with defining widgets.

At present, only the first part is available in the stubs table --
just enough so that extensions can define new themes.

These are all part of the second subsystem:

> Ttk_CreateSublayout
> Ttk_DrawLayout
> Ttk_FreeLayout
> Ttk_LayoutFindNode
> Ttk_LayoutNodeInternalParcel
> Ttk_LayoutSize
> Ttk_PlaceLayout
> Ttk_RebindSublayout

I don't consider those fully cooked yet, which is
why they're not in the stubs table right now.
I can add them if you need them, but beware that
they'll be subject to change.

(An aside: this is why I consider it important that Ttk
in the core continues to export its own stubs table,
separate from Tk's.  If we have to support all the
stuff that's currently in there from now until 8.X is
end-of-lifed, the ttk::* widgets are never going to
get any better than they are right now.)

> RegisterWidget -> Ttk_RegisterWidget?
> TtkRedisplayWidget
> TtkResizeWidget
> TtkWidgetCgetCommand
> TtkWidgetConfigureCommand
> TtkWidgetInstateCommand
> ttkCoreOptionSpecs
> TtkWidgetDoLayout
> TtkWidgetGetLayout

These are all part of the third subsystem.  The widget framework
relies heavily on statically-defined tables of function pointers,
and isn't really amenable to stubification.

However, you don't need the widget framework to use
the rest of the theme engine; the traditional Tk facilities
will work just as well.  (Tile's widget framework just
makes things a bit easier is all.)

> Also, there should be some way for a widget to specify that it
> does not want to be double-buffered. For large-area widgets like
> treectrl it isn't very efficient (and treectrl already does
> double-buffering).  Also, on composited desktops (OSX, Vista)
> isn't every toplevel already double-buffered?

That isn't supported at the moment.  So far it hasn't
been necessary, since Tile seems fast enough even under
OSX (where things end up being *triple*-buffered).

If you're not using the widget framework, you can decide
whether or not to use double-buffering in the <Expose>
handler, as per usual.

> A [ttk::style names] command would be nice for getting the
> names of existing styles, like [ttk::style theme names] and
> [ttk::style element names].

In the works.

--Joe English

  jen...@fl...

2004	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (4)	Sep (88)	Oct (30)	Nov (10)	Dec (12)
2005	Jan (31)	Feb (37)	Mar (39)	Apr (10)	May (3)	Jun (6)	Jul (23)	Aug (47)	Sep (55)	Oct (8)	Nov (6)	Dec
2006	Jan (21)	Feb (8)	Mar (17)	Apr (8)	May (26)	Jun (19)	Jul (11)	Aug (4)	Sep (17)	Oct (40)	Nov (71)	Dec (3)
2007	Jan (5)	Feb (7)	Mar (11)	Apr (6)	May (3)	Jun (4)	Jul (7)	Aug (1)	Sep	Oct (26)	Nov (12)	Dec (9)
2008	Jan (2)	Feb (1)	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec
2010	Jan	Feb	Mar (1)	Apr	May	Jun (1)	Jul (1)	Aug	Sep (1)	Oct	Nov	Dec
2011	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul	Aug (1)	Sep	Oct	Nov	Dec
2012	Jan	Feb	Mar	Apr (1)	May (1)	Jun	Jul	Aug (1)	Sep (1)	Oct (1)	Nov	Dec
2013	Jan	Feb (1)	Mar	Apr (1)	May	Jun (1)	Jul	Aug (3)	Sep	Oct	Nov	Dec
2014	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug (1)	Sep	Oct (1)	Nov	Dec
2015	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul (1)	Aug	Sep	Oct	Nov	Dec
2016	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul	Aug	Sep (1)	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul	Aug (1)	Sep	Oct	Nov	Dec
2018	Jan	Feb (1)	Mar	Apr (1)	May	Jun (1)	Jul (1)	Aug	Sep	Oct	Nov	Dec
2019	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul	Aug (1)	Sep (2)	Oct	Nov	Dec
2020	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2021	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec

tktable-tile-dev Mailing List for TkTable / Tile / Vu (Page 8)

tktable-tile-dev — Discussion about tile development