tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] tile.kit questions

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

Casey Ackels wrote:
> platforms (windows, linux, freebsd).
	...
> So, I unwrapped the tile.kit and /FreeBSD-x86/ doesn't exist. Is this=20
> a mistake or is there no FreeBSD support in tile.kit?

Whoever built tile.kit probably did not have access to a FreeBSD =
machine.  One
just needs to extend the existing kit with the right binaries.

> And if FreeBSD isn't supported, what would it take to get it=20
> supported? If its a simple recompilation, i would be more than=20
> willing to do it, provided I had instructional help (I am new to=20
> this).

Yes, it's a simple recompilation.  You would need to grab the =
appropriate
sources (ideally the same as the kit uses, for consistency with the =
runtime
tcl files), and just do the usual configure/make on it.  It's the =
install that
has to be hand-twiddled to get into the kit correctly.

Jeff

[Tile-dev] tile.kit questions

[Casey A. <ca...@sa...>]

Hi, I am in the process of overhauling my application, and would like 
to use Tile, so I have playing around with using Tile on several 
platforms (windows, linux, freebsd).

I believe using the tile.kit will be the easiest solution. However, 
when I try to do a 'package require' for tile, I get an error.

Here is the complete steps that i took:
./tclkit-freebsd6-x86
% source tile07.kit
% package require tile
couldn't load 
library "/home/casey/Downloads/Tcl/tile07.kit/lib/tile0.7.2/FreeBSD-x86/tile072.so": 
no such file or directory

So, I unwrapped the tile.kit and /FreeBSD-x86/ doesn't exist. Is this 
a mistake or is there no FreeBSD support in tile.kit?

And if FreeBSD isn't supported, what would it take to get it 
supported? If its a simple recompilation, i would be more than 
willing to do it, provided I had instructional help (I am new to 
this).

- Casey

Re: [Tile-dev] Tile background vs. Normal Tk background

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

Will Duquette wrote:
> I've got a small GUI that's using Tile widgets on a BWidgets =
PagesManager.
> (ActiveTcl 8.4.14, Linux, Tile theme is "alt").  The=20
> background color of the Tile widgets (labels, buttons, etc.)=20
> is different than the default
> background color of the frame widgets created by the PagesManager.  =20
> Calling the undocumented BWidgets command "Widget::theme on" didn't =
help.
	...
> that's really tacky.  Alternatively, is there a way to get=20
> PagesManager to use ttk::frame instead of tk::frame?

Yes, if you followed the same design pattern for doing this when =
Widget::theme
is defined.  I never extended this to PagesManager because I was using =
the
themed notebook instead (didn't need it to be tabless).  It shouldn't be =
hard
to make those mods.

Jeff

[Tile-dev] ttk::notebook vs. PagesManager

[Will D. <Wil...@jp...>]

Howdy!

Is there any way to get a ttk::notebook widget to work like a BWidgets
PagesManager, i.e., as a tab-less notebook with the displayed page being
selected programmatically?  Setting the tab -state to hidden for all  
tabs
doesn't do it; as soon as you call "$nb select" for a tab, its tab  
pops up.

Will

[Tile-dev] Tile background vs. Normal Tk background

[Will D. <Wil...@jp...>]

Howdy!

I've got a small GUI that's using Tile widgets on a BWidgets  
PagesManager.
(ActiveTcl 8.4.14, Linux, Tile theme is "alt").  The background color of
the Tile widgets (labels, buttons, etc.) is different than the default
background color of the frame widgets created by the PagesManager.   
Calling
the undocumented BWidgets command "Widget::theme on" didn't help.

Short of using a ttk::notebook widget, what can I do about this?
Is there a way to programmatically find out what the background color of
the ttk::labels is, given the current theme?  I mean, I can always
sample the screen colors manually, and set the frame backgrounds
accordingly, but that's really tacky.  Alternatively, is there a way
to get PagesManager to use ttk::frame instead of tk::frame?

Any thoughts?

Will

[Tile-dev] ttk::checkbutton with focus <Alt-Space> irregularity

[Mark G. <du...@ya...>]

I've a slight problem with checkboxes on XP SP2 when the checkbutton has focus and I want to use the Alt-Spacebar method of opening its window manager menu.
   
  If I perform the Alt-Space and cancel it with Escape the next Alt-Space shortcut will also toggle the checkbutton as soon as the Alt key is pressed. All Alt-Space sequences after that will toggle the checkbutton which has the focus on depressing the Alt key. This can of course lead to unexpected results. TK 8.4.13/Tile 0.7.8
   
  Thanks for any pointers,
   
  Mark

 
---------------------------------
Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.

Re: [Tile-dev] Nooby support here?

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

Ken Tilton wrote:
>  [...]
> >> wish seemed to get into Tile without any help, but I guess I have to
> >> give Tk a nudge. Reasonable enough. But what is the nudge? the doc says:
> >>
> >> "If you're feeling adventurous, you can try:
> >>
> >>    namespace import ttk::*"

You omitted the next sentence, which is very important: *in your
application's namespace(s)* [...]".  Don't say [namespace import ttk::*]
at global scope, this Does Not Work and Will Break Stuff.

> > OK, got this much:
> >
> >  (tk-format-now "package require tile") ;; <-- oops, needed this

That was my first guess as to what was missing...

> >  (tk-format-now "namespace import -force ttk::*")

Don't do that, see above.

> > Now I get -pady is an invalid option. Understood, but some doc I saw
> > said all options were supported for setting and querying though
> > otherwise inoperative just to make exercises such as mine (switching
> > to Tile in two minutes) feasible. Not so?

Not anymore, sorry.  Earlier Tile releases used to include
compatibility options as an experiment to see how feasible
it would be to maintain complete- or near-complete API
compatibility with Tk 8.4.  The results of the experiment
were: not very feasible.  The compatibility options caused
more problems than they solved, so were removed in the 0.7
release.

> OK, I broke down and defeated all the inappropriate options, did a
> setTheme to xpnative, and voila, it all works. Way cool. But... was
> there an easier way?

You don't need to call "setTheme"; the library startup script
automatically chooses an appropriate theme for you.

> Two other questions:
>
>   1. should I worry about that -force option?
>   2. Looking at the themes listed here
> http://tktable.sourceforge.net/tile/index.html i do not see anything
> that cries out "OS X native aqua"

That's just because Pat (who maintains the website) doesn't
have a Mac to take screenshots on :-)  The "aqua" theme --
which will be selected by default on OSX -- has a reasonably
good native look and feel.


--Joe English

Re: [Tile-dev] Nooby support here?

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

Ken Tilton wrote:
>  1. should I worry about that -force option?

It is better to consider the ttk::label and ::label commands separately 
and not simply overwrite the classic Tk commands.  You may well find 
that more advanced applications have use for both.

>  2. Looking at the themes listed here 
> http://tktable.sourceforge.net/tile/index.html i do not see anything 
> that cries out "OS X native aqua"

Don't bother with setTheme - the default theme on OS X is the native 
one.  Check out the screenshots at the link above to see it.

Jeff

Re: [Tile-dev] Nooby support here?

[Ken T. <ken...@gm...>]

Ken Tilton wrote:

> Ken Tilton wrote:
>
>> Sorry if this is the wrong place, and feel free to redirect...
>>
>> This is Tcl85 on win32. I am trying the quick-dirty way to switch to 
>> Tile: Just Load It.
>>
>> What I did was place Tile078 in my Tcl tree like this:
>>
>> \Tcl\lib\Tile....
>>
>> when I do the wish thing, all goes well, the stuff I build 
>> interactively comes up with widgets that match the widgets in the 
>> Display control panel as I switch XP themes.
>>
>> But I am driving Tcl/Tk from Lisp (via the C API).
>>
>> the window matches the current XP theme, but not the widgets. The 
>> scrollbars are the real giveaway.
>>
>> wish seemed to get into Tile without any help, but I guess I have to 
>> give Tk a nudge. Reasonable enough. But what is the nudge? the doc says:
>>
>> "If you're feeling adventurous, you can try:
>>
>>    namespace import ttk::*"
>>
>> That does not work, and neither does the alternative, specifying 
>> "ttk::button", eg. The error is something like "no such namespace"
>>
>> Damn, I am exhausted, it just occurred to me to search the archives 
>> here and use Google. :( Will commence that now, but any help on 
>> getting Tile into play using just the C API (and not talking to a 
>> wish process via a pipe) would be appreciated.
>
>
> OK, got this much:
>
>  (tk-format-now "package require tile") ;; <-- oops, needed this
>  (tk-format-now "namespace import -force ttk::*")
>
> I have the -force (which I saw described as a bad idea) because 
> without it I got "label already exists" or something to that effect.
>
> Now I get -pady is an invalid option. Understood, but some doc I saw 
> said all options were supported for setting and querying though 
> otherwise inoperative just to make exercises such as mine (switching 
> to Tile in two minutes) feasible. Not so?
>
> Still googling....

OK, I broke down and defeated all the inappropriate options, did a 
setTheme to xpnative, and voila, it all works. Way cool. But... was 
there an easier way?

Two other questions:

  1. should I worry about that -force option?
  2. Looking at the themes listed here 
http://tktable.sourceforge.net/tile/index.html i do not see anything 
that cries out "OS X native aqua"

I'll continue googling for #2

ken

[Tile-dev] Nooby support here?

[Ken T. <ken...@gm...>]

Sorry if this is the wrong place, and feel free to redirect...

This is Tcl85 on win32. I am trying the quick-dirty way to switch to 
Tile: Just Load It.

What I did was place Tile078 in my Tcl tree like this:

\Tcl\lib\Tile....

when I do the wish thing, all goes well, the stuff I build interactively 
comes up with widgets that match the widgets in the Display control 
panel as I switch XP themes.

But I am driving Tcl/Tk from Lisp (via the C API).

the window matches the current XP theme, but not the widgets. The 
scrollbars are the real giveaway.

wish seemed to get into Tile without any help, but I guess I have to 
give Tk a nudge. Reasonable enough. But what is the nudge? the doc says:

"If you're feeling adventurous, you can try:

    namespace import ttk::*"

That does not work, and neither does the alternative, specifying 
"ttk::button", eg. The error is something like "no such namespace"

Damn, I am exhausted, it just occurred to me to search the archives here 
and use Google. :( Will commence that now, but any help on getting Tile 
into play using just the C API (and not talking to a wish process via a 
pipe) would be appreciated.

ken

Re: [Tile-dev] Proposal: add/remove/forget methods for notebook andpanedwindow

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

Jeff Hobbs wrote:
> Joe English wrote:
> > Proposed change: [...]
> It looks like remove and forget would only take window names.  Any reason not
> to support tab ids as well?  Is that because you do want to error on a tabId
> that isn't a window but isn't a valid id?

Basically, yeah.  Right now, [$nb forget] takes a tab identifier,
which is a managed window-or-integer-or-other stuff.  In the
proposed scheme, it would take an arbitrary window.  

It wouldn't be too hard to make it take a managed window-or-other window-
or-integer-or-other stuff instead, but if there's no compelling
reason to I'd rather not complicate things.


--Joe English

  jen...@fl...

Re: [Tile-dev] Proposal: add/remove/forget methods for notebook andpanedwindow

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

Joe English wrote:
> Proposed change:
> 
> 	$nb remove $win
> 	    Unmaps the slave window $win but leave it managed.
> 	    If $win is not currently managed by $nb, do nothing.
> 
> 	$nb add $win [... options ...]
> 	    Manage $win as a slave and add it to the end of the list
> 	    if it is not currently managed by $nb.  Remap $win at
> 	    its previous position if it is currently managed by $nb
> 	    but unmapped.  Do nothing if it is already mapped and managed.
> 
> 	$nb forget $win
> 	    Unmap and unmanage $win.  Do nothing if $win is not
> 	    currently managed by $nb.
> 
> ... and the same thing for panedwindow widgets.
> 
> [$nb remove $win] would do basically the same thing that
> [$nb tab $win -state hidden] currently does (just implemented 
> differently); the latter could eventually be phased out.
> 
> The only incompatibility would be that [$nb forget] would 
> only take window names, not arbitrary tab identifiers.

It looks like remove and forget would only take window names.  Any reason not
to support tab ids as well?  Is that because you do want to error on a tabId
that isn't a window but isn't a valid id?  I guess that would be harder to
support and keep the semantics that double-forgetting shouldn't error.

BTW, the reason that I encountered the bug is that in VFSE (Explorer-like
app), if you hid the Folders List, one of the paths did forget twice.  That
would be harmless with grid/pack, but I got caught by panedwindow.

Jeff

[Tile-dev] Proposal: add/remove/forget methods for notebook and panedwindow

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

Bug #1614361 got me to thinking about a potential improvement
for how the ttk::notebook and ttk::panedwindow widgets manage
their children.

The current API is:

	$nb add $win [ ... options ... ]
	    Manage $win as a slave and add it to the end of the list.
	    It is an error if $win is already managed by $nb.

	$nb forget $tabid
	    Unmanages $tabid; $tabid is either the widget path
	    of a managed slave, an integer index, or one of
	    the other syntactic forms described in "TAB IDENTIFIERS".

There's also an [$nb insert ...] command, which can add tabs
at a specific position or move existing tabs around.  The
panedwindow supports the same interface (with a couple minor
differences).

Proposed change:

	$nb remove $win
	    Unmaps the slave window $win but leave it managed.
	    If $win is not currently managed by $nb, do nothing.

	$nb add $win [... options ...]
	    Manage $win as a slave and add it to the end of the list
	    if it is not currently managed by $nb.  Remap $win at
	    its previous position if it is currently managed by $nb
	    but unmapped.  Do nothing if it is already mapped and managed.

	$nb forget $win
	    Unmap and unmanage $win.  Do nothing if $win is not
	    currently managed by $nb.

... and the same thing for panedwindow widgets.

[$nb remove $win] would do basically the same thing that
[$nb tab $win -state hidden] currently does (just implemented
differently); the latter could eventually be phased out.

The only incompatibility would be that [$nb forget] would only
take window names, not arbitrary tab identifiers.

Opinions?


--Joe English

  jen...@fl...

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

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

Will Duquette wrote:
> On Nov 23, 2006, at 12:48 PM, Joe English wrote:
> > The "default" theme currently serves two purposes:
> > it's the default theme under X11 [...],
> > and it's also used as the final fallback source
> > for elements and layouts that aren't defined in
> > other themes.
>
> If you're going to rename "default" anyway....why
> not just leave "default" as the standard X11 style
> and create a new style, e.g., "root", which "default"
> draws on?

Just trying to minimize the impact on existing code.


--JE

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

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

>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 

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

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

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

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

[Will D. <Wil...@jp...>]

Joe,

If you're going to rename "default" anyway....why
not just leave "default" as the standard X11 style
and create a new style, e.g., "root", which "default"
draws on?

Will

On Nov 23, 2006, at 12:48 PM, Joe English wrote:

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

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

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

Jeff Hobbs wrote:
> Joe English wrote:
> > For example, there's the fallback Radiobutton.indicator
> > and Checkbutton.indicator elements.  (BTW, these are
> > scheduled to be renamed to "radio" and "check",
>
> Why?  I think the common "indicator" works well, and is consistent with
> general documentation of the elements.

"indicator" is too heavily overloaded.

Tile currently uses "Checkbutton.indicator", "Radiobutton.indicator",
"Menubutton.indicator", and "Treeitem.indicator" elements, all with
different functional roles.  Other widgets will want to reuse
these elements, and themes will want to provide widget-specific
variants for them (think of [ttk::menu]s).



--Joe English

  jen...@fl...

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

[Eckhard L. <ec...@we...>]

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

Re: [Tile-dev] Tile-aware treectrl

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

Joe English wrote:
> Two items on your list aren't planned for inclusion,
> I was hoping to get rid of these:
> 
>> Ttk_LayoutFindNode
>> Ttk_LayoutNodeInternalParcel
> 
> These don't seem quite right -- especially Ttk_LayoutNodeInternalParcel
> (the name itself is a sign that the interface isn't right yet) --
> what did you need these for?


Ttk_LayoutFindNode is used by a bunch of widgets but I
was just following the example provided by treeview,
namely to get the "client" node where the contents of
the tree should be drawn (inside borders).

Ttk_LayoutNodeInternalParcel was used in one instance
for the same reason treeview uses it, namely to subtract
the internal padding of the "client" node. I also used
it in two hack-ish spots to subtract any padding around
the indicators so I could align them with the dotted
lines that treectrl draws between items.

-- Tim Baker

Re: [Tile-dev] Tile-aware treectrl

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

Tim Baker wrote:

> My Tile-ified treectrl draws the headers and indicators using
> Tile now. In addition to some already-exported symbols it
> only requires the following exports:
>
> [... see below ...]
>
> There's no rush getting these exported (if they will be). It
> is just to give an indication of what widget authors may need
> in order to create Tile-ified widgets.

OK, good!  That's pretty much what I expected would need to
be exported for widget authors.

I don't like the names (more on that later), and the
function signatures might need a few tweaks, but the
following are all scheduled for inclusion in the public
stubs table:

> Ttk_CreateLayout
> Ttk_CreateSublayout
> Ttk_DrawLayout
> Ttk_FreeLayout
> Ttk_LayoutSize
> Ttk_PlaceLayout
> Ttk_RebindSublayout

Two items on your list aren't planned for inclusion,
I was hoping to get rid of these:

> Ttk_LayoutFindNode
> Ttk_LayoutNodeInternalParcel

These don't seem quite right -- especially Ttk_LayoutNodeInternalParcel
(the name itself is a sign that the interface isn't right yet) --
what did you need these for?


--Joe English

  jen...@fl...

Re: [Tile-dev] Tile-aware treectrl

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

My Tile-ified treectrl draws the headers and indicators using
Tile now. In addition to some already-exported symbols it
only requires the following exports:

Ttk_CreateLayout
Ttk_CreateSublayout
Ttk_DrawLayout
Ttk_FreeLayout
Ttk_LayoutFindNode
Ttk_LayoutNodeInternalParcel
Ttk_LayoutSize
Ttk_PlaceLayout
Ttk_RebindSublayout

There's no rush getting these exported (if they will be). It
is just to give an indication of what widget authors may need
in order to create Tile-ified widgets.

-- Tim Baker

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

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

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

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

[Eckhard L. <ec...@we...>]

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

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

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

Joe English wrote:
> For example, there's the fallback Radiobutton.indicator
> and Checkbutton.indicator elements.  (BTW, these are
> scheduled to be renamed to "radio" and "check", 

Why?  I think the common "indicator" works well, and is consistent with
general documentation of the elements.

Jeff