tktable-tile-dev — Discussion about tile development

[Tile-dev] Pending changes: "default" theme

[Joe E. <jen...@fl...>]

The "default" theme currently serves two purposes:
it's the default theme under X11 (unless overridden
by user preferences in the X resource database),
and it's also used as the final fallback source
for elements and layouts that aren't defined in
other themes.

Although the design constraints for these two roles
have a lot of overlap -- elements should be plain
and unobtrusive and not clash too badly with anything else --
there are cases where they're in conflict.

For example, there's the fallback Radiobutton.indicator
and Checkbutton.indicator elements.  (BTW, these are
scheduled to be renamed to "radio" and "check", respectively).
These don't work properly without further script-level
configuration to set state-dependent resources.
That is, if you do:

    style theme create empty
    tile::setTheme empty

ttk::radiobuttons and ttk::checkbuttons will be non-functional;
the appearance doesn't change with the state.

So: the current plan is to introduce a new theme
(probably called "plain"), which will be used as the
default on X11.  Look and feel will match Tile's
current "default" theme (that is, similar to 2003-era
out-of-box Gnome and/or as_style.tcl from Tklib).

The "default" theme will only be used to provide default
element implementations and layout specifications; there
will be no [style configure] or [style map] settings,
and it won't be listed in [ttk::themes].

"default" should probably be renamed "root" or ".",
if that can be done without causing transition problems
(see earlier thread on compatibility policy).


--Joe English

  jen...@fl...

Re: [Tile-dev] tielqt & Lableframe background drawing...

[Joe E. <jen...@fl...>]

[I wrote]

> Georgios Petasis wrote:
> > Is there a problem that the labeframe widget has a composite text
> > element? Can it be split into a background and a plain text element? The
> > the text element will remain the regular one, and all background
> > painting to be done on the text background element?
> 
> That's the idea.
> 
> One thing to watch out for is that the ttk::labelframe widget is
> looking for an element named "*.text"  [...]

Oops!  I forgot to mention: this is going to change 
(possibly in Tile 0.8.0/Tk 8.5b1, more likely in Tile 0.8.2).

The current implementation isn't as customizable as it
should be; in future, the Labelframe will use a sublayout
"TLabelframe.label" instead of moving the "text" element
in the main layout around.


--Joe English

  jen...@fl...

Re: [Tile-dev] plans for treeview inclusion

[Csaba N. <csa...@t-...>]

Jeff Hobbs schrieb:
> I had a short chat with Joe on the Tcl'er chat.  With some commitment to
> address the x scrolling issue and (time permitting) column weighting, we'll go
> with including this in 8.5.
> 

This is really great news.  Many thanks!

Csaba

-- 
Csaba Nemethi   http://www.nemethi.de   mailto:csa...@t-...

Re: [Tile-dev] Tile compatibility policy and the core merge

[Joe E. <jen...@fl...>]

Georgios Petasis wrote:

> I cannot see why doing "package require tile" in Tk 8.5a6 should produce
> chaos.
> Isn't the tile package in 8.5a6 declared as a static package using
> Tcl_StaticPackage?

No, not at the moment.


> If it is registered as a static package, why tcl will try to load
> another version of tile (anywhere in the auto_path) sinse it will be
> already loaded?

Right, if it were registered as a static package, that would
prevent any problems related to conflicting copies.


--Joe English

  jen...@fl...

Re: [Tile-dev] Tile compatibility policy and the core merge

[Joe E. <jen...@fl...>]

[ Followups to tcl...@li... ]

On tktable-tile-dev, Jeff Hobbs wrote:
>
> [...] 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).

This might merit further discussion.  (It pertains to Tile
as a whole, not just the ttk::treeview widget).


Although having merged Tile into the core has certainly
slowed down development (well, that plus work and real life),
it was never my intention to *stop* development on Tile.
There are still a lot of improvements to be made, including
new features and backward-incompatible changes.

TIP#248 only said, in essence, "Put Tile into the core",
but it was silent on the subject of future maintenance.
Was the intent to take a snapshot and then tether ttk::*
evolution to the core's release schedule, strict compatibility
policies and all, or will feature changes in core patchlevel
releases be allowed?

(My take: Tile development can be arranged to accomodate the
core's release schedule, but I don't think that shackling
it with the core's compatibility policy is in anyone's best
interest at this point.)


--Joe English

  jen...@fl...

Re: [Tile-dev] tielqt & Lableframe background drawing...

[Joe E. <jen...@fl...>]

Georgios Petasis wrote:
>
> Thank you for clarifying the situation. I had suspected this also my
> self, and I have even tried
>
> style configure TLabelframe -background [currentThemeColour -background]
>
> my self. It partially solves the problem: in Qt styles that use a pixmap
> background, the solution does not work.
>
> Is there a problem that the labeframe widget has a composite text
> element? Can it be split into a background and a plain text element? The
> the text element will remain the regular one, and all background
> painting to be done on the text background element?

That's the idea.

One thing to watch out for is that the ttk::labelframe widget is
looking for an element named "*.text" -- so TileQT's "Labelframe.text"
element should actually be a "background fill" element.
In the Labelframe layout, add a "real" text element as a child --
something like:

	style layout TLabelframe {
	    Labelframe.border
	    Labelframe.text -children { Labelframe.labeltext }
	}

The best way to define the "Labelframe.labeltext" element is
to copy it from the default theme:

	style element create Labelframe.labeltext from default text


--Joe English

  jen...@fl...

Re: [Tile-dev] Tile compatibility policy and the core merge

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:
> > [Joe English]
> > 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.
> > [...]
>
> 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), an
> 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 ...

That isn't the main problem.  The main problem is that when
tile.so's copy of Ttk_Init() gets called, it replaces the
core's copy of the interp-specific data and other internal
data structures.  This stuff doesn't expect to get deleted
until the interp is destroyed; who knows what will happen?

I *think* that as long as the app calls [package require tile]
before creating any ttk::* widgets, this will be harmless,
but I won't swear to it.

Another issue that isn't an immediate problem but will become
much more severe in the long term is that on ELF-based systems
(e.g., most Unixes), most of the entry points in tile.so
get resolved to the core's copy instead of tile's.

This doesn't hurt today, since both routines are identical at
the moment, but down the road it will become a big problem
as the internals evolve and diverge.  Tk 8.5 apps that call
[package require tile] will crash and burn in unpredictable
ways if the wrong version of the tile package happens to be
lying around on the system.  I'd really like to avoid this:
putting Ttk into the core was supposed to make deployment easier,
and this is a potential landmine field.

 . . .

Re: TkClassicDefaultFont -- this should probably just be removed.
It makes the "classic" theme look like 8.4 on X11, but it's a
mismatch on Windows, OSX, and X11+Xft.  (Plus it creates an
extra named font that's almost never used.)

And re: ttk::theme::default -- more on that later.


--Joe English

Re: [Tile-dev] a tale of 2 trees

[Donal K. F. <don...@ma...>]

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.

[Tile-dev] plans for treeview inclusion

[Jeff H. <je...@ac...>]

I had a short chat with Joe on the Tcl'er chat.  With some commitment to
address the x scrolling issue and (time permitting) column weighting, =
we'll go
with including this in 8.5.

Mind you, this will probably gets lots of RFEs (I suspect more than any =
other
widget), but I would resist trying to make this an end-all-be-all.  I =
still
favor treectrl (or godzillatree, as the new name will be ;) ) as a =
kick-ass
future widget for inclusion.

Where treeview should be useful is as an improvement on the core =
listbox.
Perhaps treelist is more appropriate, but we aren't changing names now.

What treectrl offers is something akin to what the canvas or text widget
provide to Tk.  Unparalleled ease of use to really cool functionality.  =
While
treectrl isn't *quite* as easy to use, the functionality is another =
notch up
the coolness scale.

Jeff

Re: [Tile-dev] a tale of 2 trees

[Tim B. <tre...@ho...>]

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

Re: [Tile-dev] a tale of 2 trees

[Jeff H. <je...@ac...>]

Kevin Kenny wrote:
> Will Duquette wrote:
> > This is exactly my point--there are uses for a tree widget
> > that do *not* resemble a rich multicolumn listbox.
>=20
> je...@ac... said:
> > Like?
>=20
> Well, you could make a nicer tk_chooseDirectory for unix.

Case in point - if you really wanted to do this right, you would use =
treectrl.
I don't think treeview could improve on the current X11 version, but =
that
depends on your view preferences.

Jeff

Re: [Tile-dev] a tale of 2 trees

[<ke...@cr...>]

je...@ac... said:
> 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. 

A fairer comparison would be with text, canvas or tktable.  I expect
these four widgets to be pretty huge, because they do so very much.

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [Tile-dev] a tale of 2 trees

[<ke...@cr...>]

Will Duquette wrote:
> This is exactly my point--there are uses for a tree widget 
> that do *not* resemble a rich multicolumn listbox.

je...@ac... said:
> Like? 

Well, you could make a nicer tk_chooseDirectory for unix.

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [Tile-dev] a tale of 2 trees

[Jeff H. <je...@ac...>]

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

Re: [Tile-dev] a tale of 2 trees

[Kevin W. <kw...@co...>]

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

Re: [Tile-dev] a tale of 2 trees

[Jeff H. <je...@ac...>]

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

Re: [Tile-dev] a tale of 2 trees

[Csaba N. <csa...@t-...>]

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

Re: [Tile-dev] a tale of 2 trees

[Jeff H. <je...@ac...>]

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

Re: [Tile-dev] a tale of 2 trees

[Kevin W. <kw...@co...>]

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

Re: [Tile-dev] a tale of 2 trees

[Kevin W. <kw...@co...>]

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

Re: [Tile-dev] a tale of 2 trees

[Jeff H. <je...@ac...>]

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

Re: [Tile-dev] a tale of 2 trees

[Brett S. <bre...@ya...>]

(apologies about not embedding this message, email client problem).=0A=0ATh=
is situation sucks :)=0A=0AI have used treeview widget in the past for some=
 internal tools (i.e. small audience). Although I found it was sufficient f=
or what I wanted, I was not 100% satisfied. I had started an email client (=
really an outlook clone) using Tile (and hence treeview), but soon began to=
 understand that this probably would not fly well in a larger audience. At =
that point I had started learning tktreectrl (although I never really got t=
hrough it due to my second son being born). I do have to say that I have no=
t tried the last set of improvements Joe made to treeview, so I'm not 100% =
up to speed on it's capabilities. I do know that the new bbox method did he=
lp me out.=0A=0ASo, I'm kind of on the fence but I agree with Jeff's points=
. I have also one other nitpick....the lines that connect the tree elements=
 are not drawn. This is not a huge deal, but pretty much every tree widget =
I have seen does this. =0A=0AI really would like to see treeview in the cor=
e. But, I'm afraid *more* people than not will try it, and will not like it=
....and probably won't come back to it (isn't that what happened to Tcl in =
some sense?). If it would go in the core as it stands now, I might use it, =
but probably just for very small audience apps. When I do fully learn tktre=
ectrl, I will probably replace treeview with that (unless treeview improves=
 in the near future).=0A=0AAlso, if both treeview and tktreectrl go in the =
core, I agree with Will, that we need to rename tktreectrl. I think people =
will just be confused if they see 2 widgets with similiar names.=0A=0AMy $0=
.02=0A =0A--brett (still on the fence)=0A=0A=0A----- Original Message ----=
=0AFrom: Jeff Hobbs <je...@ac...>=0ATo: Csaba Nemethi <csaba.neme=
th...@t-...>=0ACc: tkt...@li...; Will Duquett=
e <Wil...@jp...>; Tim Baker <tre...@ho...>=0ASen=
t: Wednesday, November 22, 2006 1:37:13 PM=0ASubject: Re: [Tile-dev] a tale=
 of 2 trees=0A=0ACsaba Nemethi wrote:=0A> Jeff Hobbs schrieb:=0A> > Your po=
ints are in general correct, but overlook the direct remarks I=0A> > made b=
elow.  Those features are certainly required for a decent dir =0A> > browse=
r, but they are necessary for many other type of apps as well. =0A> > The l=
ack of these in treeview is why people have turned to pure Tcl =0A> > alter=
natives even when treeview was available.  If you want to look at =0A> > tr=
eeview as a multicolumn listbox, then it really fails in 2 areas - no =0A> =
> x scrolling and the inability to control stretch/shrink of columns.  Joe =
=0A> > has said he likely won't have the time to address these before 8.5.0=
, =0A> > and thus I don't think it serves the core much to distract with th=
e =0A> > treeview.=0A=0A> While I generally agree with your criticism conce=
rning the current =0A> development state of the treeview widget, I would ha=
ve a quite serious =0A> problem if treeview wouldn't be integrated into the=
 core.  The reason is =0A> that in the tile-enabled version of Tablelist I =
make use of some =0A> treeview-related elements, like Treeheading.border an=
d Treeheading.cell.=0A=0AWhile this is an interesting aspect, it is not str=
ictly in favor of the=0Atreeview.  It is perhaps possible to have the eleme=
nts without the widget.=0A=0A> Also, your intention (decision?) to exclude =
treeview from the core =0A> doesn't take into account that there are quite =
a few people who already =0A> use treeview (in spite of its relatively earl=
y development state). =0A> After all, this wouldn't be the first widget in =
the core whose early =0A> versions are not yet quite satisfactory.=0A=0APle=
ase identify these people.  That is what I had hoped this discussion would=
=0Ado - flush out users of treeview to advocate that they are perfectly hap=
py=0Ausing it for X, Y and Z.  On the contrary, I have received only more=
=0A*negative* indicators.  I am still open either way, but I have been push=
ed=0Afarther against in the last few days without anybody really advocating=
 for on=0Acore widget value.=0A=0AJeff=0A=0A=0A----------------------------=
---------------------------------------------=0ATake Surveys. Earn Cash. In=
fluence 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 bri=
ef surveys - and earn cash=0Ahttp://www.techsay.com/default.php?page=3Djoin=
.php&p=3Dsourceforge&CID=3DDEVDEV=0A_______________________________________=
________=0ATktable-tile-dev mailing lis...@li...=
ge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/tktable-tile-dev=0A=
=0A=0A=0A=0A

Re: [Tile-dev] a tale of 2 trees

[Jeff H. <je...@ac...>]

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

Re: [Tile-dev] a tale of 2 trees

[Kevin W. <kw...@co...>]

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

Re: [Tile-dev] a tale of 2 trees

[Jeff H. <je...@ac...>]

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