tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] Style settings precedence

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

[I wrote]:
>
> So [style map ...] settings override widget settings. [...]
> However, I can't think of any use cases where this ends up
> being helpful [...]

Found one: aquaTheme.tcl uses this feature to disable the
"-underline" option on buttons and other widgets:

|    style map . -underline {{} -1}

This is mostly a convenience hack for cross-platform portability.
Macintosh applications don't traditionally use underlining to highlight
mnemonics (and the "Alt" modifier doesn't work on OSX anyway).
The idea was that apps developed for Windows or X11 wouldn't
need to conditionally remove all the "-underline" specifications
when running under OSX.

So this hack won't work any more.  That's probably not a big deal.


--Joe English

  jen...@fl...

Re: [Tile-dev] Style settings precedence

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

My reading of your list ordering had me questioning immediately the sense of
#1 and #2 order.  I don't know that I'm relying on it (I have various
specialized bits), but I would vote to modify it regardless.

Jeff

Joe English wrote:
> Currently, the Tile theme engine uses the following 
> precedence order for computing element options:
> 
>     1. Dynamic settings specified by [style map ...]
>     2. Widget options specified by [$w configure ...]
>     3. Style defaults specified by [style configure ...]
>     4. Built-in defaults supplied by the element
> 
> So [style map ...] settings override widget settings.
> 
> If I remember correctly, the rationale for this order was so 
> that [style map ...] settings would act the same way as the 
> state-specific widget options like "-activeforeground" that 
> they replaced.  
> 
> However, I can't think of any use cases where this ends up 
> being helpful, and there's at least one case where it's 
> undesirable (see #1517110).  I'm starting to think that #1 
> and #2 should be swapped, so that widget options always take 
> precedence.
> 
> Any thoughts?  Is anyone relying on the current behavior?

[Tile-dev] Style settings precedence

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

Currently, the Tile theme engine uses the following precedence
order for computing element options:

    1. Dynamic settings specified by [style map ...]
    2. Widget options specified by [$w configure ...]
    3. Style defaults specified by [style configure ...]
    4. Built-in defaults supplied by the element

So [style map ...] settings override widget settings.

If I remember correctly, the rationale for this order was so 
that [style map ...] settings would act the same way as the
state-specific widget options like "-activeforeground"
that they replaced.  

However, I can't think of any use cases where this ends up 
being helpful, and there's at least one case where it's undesirable
(see #1517110).  I'm starting to think that #1 and #2 should be
swapped, so that widget options always take precedence.

Any thoughts?  Is anyone relying on the current behavior?


--Joe English

Re: [Tile-dev] odd background state...

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

Vince Darley wrote:
> On 6/27/06, Joe English <jen...@fl...> wrote:
> > Here's what's probably happening:
> >
> > The Tile widgets have a built-in handler for ActivateNotify
> > and DeactivateNotify events that clears (resp. sets) the
> > TTK_STATE_BACKGROUND bit.
> >
> > When a window is activated/deactivated, macosx/tkMacOSXWm.c
> > calls TkGenerateActivateEvents(), which calls TkQueueEventForAllChildren(),
> > which in turn skips over children that aren't currently mapped.
>
> That sounds pretty sensible.  Does that mean this is a bug in Tile, or
> that the above seemingly sensible behaviour of TkAqua is wrong? (in
> which case we should file a bug report against Tk).


I think it would be more useful if Tk delivered <Activate>/<Deactivate>
events to unmapped windows; otherwise it takes a lot more work
for widgets to keep track of whether or not their containing
toplevel is frontmost (which is what Tile is trying to do...)


The core [button] widget on OSX seems to have a similar problem
wrt. the "inactive" appearance getting out of sync.  Try this 
on OSX:

	toplevel .t1 ; pack [button .t1.b -text T1]
	toplevel .t2 ; pack [button .t2.b -text T2]

Focus on .t1, then on .t2; both buttons should appear in the
active state (black text).  Then set the focus to another
application; .t2.b becomes inactive (gray text), but .t1.b
does not.

It looks like TkMacOSXDrawControl() decides whether to draw
in the inactive state based on whether the application as a whole
is frontmost.  The button widget schedules a redisplay whenever
it receives an <Activate> or <Deactivate> event, but these
events aren't delivered to all windows when the app loses focus.
So when you switch from .t2 to another application, .t1 doesn't
redraw itself.

The Tile widgets (try to) base this decision on whether their
containing toplevel has the focus.  I'm not sure which (if either)
is correct.  Clues may be here:

    <URL: http://developer.apple.com/documentation/Cocoa/Conceptual/WinPanel/
    	Concepts/ChangingMainKeyWindow.html >


--Joe English

  jen...@fl...

Re: [Tile-dev] Tk Tile & Windows

[Michael F. <mi...@pc...>]

Jeff Hobbs wrote:
> Michael Foord wrote:
>   
>> I use Tk with Python (Tkinter).
>>
>> I have successfully got Tile working with Python and Windows 
>> XP, using the pre-built dll provided with the 0.7.2 distribution.
>>
>> The 0.7.6 announcement says that a prebuilt windows binary 
>> 'may' be available. It isn't available for download via 
>> sourceforge (yet). Does anyone have a successfully built 
>> binary for windows that I could use ?
>>     
>
> I think that ActiveState has assisted in keeping module authors lazy by
> providing a recurring update of binaries with their modules, tile included.  I
> believe a more recent version of tile can be found in the latest ActiveTcl.
>
>   
Thanks for the reply Jeff.

I'll check out the Active TCL distribution.

>> Next I need to work out how to style my widgets from Python...
>>     
>
> Any questions in particular?  At worst, you fall back to calling direct Tcl
> through the eval method, but it might make sense to better support the style
> command in Python/Tkinter moving forward (as ttk::style will be core to Tk
> 8.5).
>   
With tile I can't use all the normal options to create a button, but I 
should use styles instead. This is fine, but making the correct Tcl 
calls from Python is possibly slightly esoteric from a Python 
programmers point of view.

When I went to the tile doc page on "Style", it showed just an overview 
- with no actual details.

http://tktable.sourceforge.net/tile/doc/style.html

This probably isn't a problem, because there already exists a thin 
Python wrapper around Tile widgets for Python. If you pass in options, 
it builds the Tcl calls for you. It looks quite easy to use, and also 
makes the Tcl -> Python mapping clear. It doesn't illustrate to me which 
options are available though.

http://mfranklin.is-a-geek.org/docs/Tile/index.html

However, I'm not quite at that point in my code yet. :-)

When I am, you can rest assured I'll be back with questions.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml



>   
>> (Oh and congratulations, Tile looks very good - thanks.)
>>     
>
> On behalf of the various participants, you're welcome!
>
>   Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/
>
>
>
>
>   

Re: [Tile-dev] creating mega-entry (search) widgets?

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

Joe English wrote:
> Last week, Jeff Hobbs wrote:
	...
> It's not necessary to redefine the "MenuEntry" layout in=20
> every available theme -- you can define it just once in the=20
> "default" theme:
	...
> and all other themes will inherit it.
>=20
> Same goes for the MenuEntry.icon element -- you can use:

Thanks for the recommendation.

> The other style settings, OTOH --
>=20
> | style configure MenuEntry -padding $pad
> | style map MenuEntry -image [list disabled ::widget::img_menuentry]
>=20
> *do* need to be respecified in each theme.  I don't have a=20
> good solution for that.

These are actually not used in the latest CVS.  I actually had a =
question on
that ... the -padding that I eventually applied to the MenuEntry.icon =
only
seemed "odd", but it worked across platforms.  Why is that -padding
inconsistent with the general usage?

> [ An aside: here, I'd recommend using a one-part name for the element =
--
>   "menuEntryIcon" instead of "MenuEntry.icon" -- since that's less =
likely
>   to run into conflicts if some other custom widget in some other =
theme
>   defines its own "*.icon" element.  The full ramifications
>   of the theme engine's current fallback/inheritance strategies
>   are not entirely clear at present  :-( ]

I noticed that.  I even tried to go through the code a bit ... =
unsuccessfully.
I'll modify the name, but it would be nice to have this kind of naming =
"work".

Jeff

Re: [Tile-dev] Tk Tile & Windows

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

Michael Foord wrote:
> I use Tk with Python (Tkinter).
>=20
> I have successfully got Tile working with Python and Windows=20
> XP, using the pre-built dll provided with the 0.7.2 distribution.
>=20
> The 0.7.6 announcement says that a prebuilt windows binary=20
> 'may' be available. It isn't available for download via=20
> sourceforge (yet). Does anyone have a successfully built=20
> binary for windows that I could use ?

I think that ActiveState has assisted in keeping module authors lazy by
providing a recurring update of binaries with their modules, tile =
included.  I
believe a more recent version of tile can be found in the latest =
ActiveTcl.

> Next I need to work out how to style my widgets from Python...

Any questions in particular?  At worst, you fall back to calling direct =
Tcl
through the eval method, but it might make sense to better support the =
style
command in Python/Tkinter moving forward (as ttk::style will be core to =
Tk
8.5).

> (Oh and congratulations, Tile looks very good - thanks.)

On behalf of the various participants, you're welcome!

  Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/

Re: [Tile-dev] odd background state...

[Vince D. <vin...@gm...>]

On 6/27/06, Joe English <jen...@fl...> wrote:
> Here's what's probably happening:
>
> The Tile widgets have a built-in handler for ActivateNotify
> and DeactivateNotify events that clears (resp. sets) the
> TTK_STATE_BACKGROUND bit.
>
> When a window is activated/deactivated, macosx/tkMacOSXWm.c
> calls TkGenerateActivateEvents(), which calls TkQueueEventForAllChildren(),
> which in turn skips over children that aren't currently mapped.

That sounds pretty sensible.  Does that mean this is a bug in Tile, or
that the above seemingly sensible behaviour of TkAqua is wrong? (in
which case we should file a bug report against Tk).

Vince.

Re: [Tile-dev] creating mega-entry (search) widgets?

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

Last week, Jeff Hobbs wrote:

> As promised, attached is a megawidget variant of Michael's SearchEntry.
>   It's for placement in my tklib widget package, so it uses that
> framework (which basically means it is a snidget).

A few notes:

In proc ::widget::createMenuEntryLayout, you have:

>     foreach theme [style theme names] {
>	[...]
> 	style theme settings $theme {
> 	    style layout MenuEntry { [...] }
> 	    style element create MenuEntry.icon image [...]
> 	}
>	[...]
>     }

It's not necessary to redefine the "MenuEntry" layout in every
available theme -- you can define it just once in the
"default" theme:

| style theme settings "default" {
|     style layout MenuEntry {
| 	Entry.field -children {
| 	    MenuEntry.icon -side left
| 	    Entry.padding -children { Entry.textarea }
| 	}
|     }
| }


and all other themes will inherit it.

Same goes for the MenuEntry.icon element -- you can use:

| style theme settings "default" {
|     style element create MenuEntry.icon image ::widget::img_menuentry
| }


and this will be automagically inherited too.


[ An aside: here, I'd recommend using a one-part name for the element --
  "menuEntryIcon" instead of "MenuEntry.icon" -- since that's less likely
  to run into conflicts if some other custom widget in some other theme
  defines its own "*.icon" element.  The full ramifications
  of the theme engine's current fallback/inheritance strategies
  are not entirely clear at present  :-( ]


The other style settings, OTOH --

| style configure MenuEntry -padding $pad
| style map MenuEntry -image [list disabled ::widget::img_menuentry]


*do* need to be respecified in each theme.  I don't have a good
solution for that.


[ Another aside: The current fallback/inheritance strategies
  seem to work pretty well for defining new themes, and work
  sort-of-OK for defining custom widgets, but if the application
  needs to support custom widgets *and* arbitrary themes, they don't
  work very well at all. ]


> The image isn't configurable ... it's easy if I allow it
> across all instances (modify the master image), but for each
> menuentry will be trickier.

I don't have a good solution for that, either :-(


I had some comments on the class bindings, but it looks like
most of those issues have been addressed in the tklib CVS version.


--Joe English

  jen...@fl...

Re: [Tile-dev] odd background state...

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

Bryan Oakley wrote:
> [...]
> I have an entry widget that, when it gains focus, 'pack forgets' one
> frame of widgets and packs a different frame of widgets. When it loses
> focus it does the opposite (think: context-sensitive toolbar).
>
> If I click in the entry, the other set of widgets shows up fine. The
> problem comes when I then click on another app, which causes my app to
> lose focus and go into the background. This causes the frames to swap
> due to the FocusOut binding and everything gets the "background" state.
> So far, so good.
>
> However, when I again click in the entry which brings my app to the
> front and sets the focus, all the tile checkbuttons have a state of
> "background" even though it is the front-most app (and thus, appear
> dimmed, yet still enabled).


Here's what's probably happening:

The Tile widgets have a built-in handler for ActivateNotify
and DeactivateNotify events that clears (resp. sets) the
TTK_STATE_BACKGROUND bit.

When a window is activated/deactivated, macosx/tkMacOSXWm.c
calls TkGenerateActivateEvents(), which calls TkQueueEventForAllChildren(),
which in turn skips over children that aren't currently mapped.

So the 'background' state will get out of sync for any tile widgets
that are mapped when their toplevel loses focus but unmapped when
it gets it back.


> Adding ".button state {}" doesn't seem to have any effect.

That's correct: in [$w state $statespec], $statespec is a _list_
of state flags.  Passing an empty list is a no-op.

> Does this ring any bells? Currently my <FocusIn> proc looks something
> like this:
>
>    proc focusIn {} {
>      place .sb ...
>      raise .sb
>      .sb state ""
>      foreach w [pack slaves .sb] {
>        $w state ""

Use '$w state !background' here instead.
That should fix the problem.

>      }
>    }


--Joe English

[Tile-dev] Tk Tile & Windows

[Michael F. <mi...@pc...>]

Hello all,

I use Tk with Python (Tkinter).

I have successfully got Tile working with Python and Windows XP, using
the pre-built dll provided with the 0.7.2 distribution.

The 0.7.6 announcement says that a prebuilt windows binary 'may' be
available. It isn't available for download via sourceforge (yet). Does
anyone have a successfully built binary for windows that I could use ?

Next I need to work out how to style my widgets from Python...

(Oh and congratulations, Tile looks very good - thanks.)

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

[Tile-dev] Tk Tile & Windows

[Fuzzyman <fuz...@vo...>]

Hello all,

I use Tk with Python (Tkinter).

I have successfully got Tile working with Python and Windows XP, using
the pre-built dll provided with the 0.7.2 distribution.

The 0.7.6 announcement says that a prebuilt windows binary 'may' be
available. It isn't available for download via sourceforge (yet). Does
anyone have a successfully built binary for windows that I could use ?

Next I need to work out how to style my widgets from Python...

(Oh and congratulations, Tile looks very good - thanks.)

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Re: [Tile-dev] odd background state...

[Vince D. <vin...@gm...>]

I've seen the same problem with widgets "stuck" in the background
dimmed state.  I don't have a simple reproducible case, so if you have
one it'd be good!

Vince.

On 6/23/06, Bryan Oakley <oa...@ba...> wrote:
> Bryan Oakley wrote:
> > I'm encountering a problem with tile widgets getting into a background
> > state on MacOSX. I don't know if this is a bug in tile or a bug in my
> > expectations.
> It still seems like maybe a bug in tile. If anybody's interested I'll
> try to make a small reproduceable case.

Re: [Tile-dev] odd background state...

[Bryan O. <oa...@ba...>]

Bryan Oakley wrote:
> I'm encountering a problem with tile widgets getting into a background 
> state on MacOSX. I don't know if this is a bug in tile or a bug in my 
> expectations.
 >
> .... Adding ".button state {}" doesn't seem to have any effect.

...but I just discovered that ".button state {!background}" does what I 
need. Funny how re-reading *all* the documentation sometimes yields 
better results than just skimming...

It still seems like maybe a bug in tile. If anybody's interested I'll 
try to make a small reproduceable case.

[Tile-dev] odd background state...

[Bryan O. <oa...@ba...>]

I'm encountering a problem with tile widgets getting into a background 
state on MacOSX. I don't know if this is a bug in tile or a bug in my 
expectations.

I have an entry widget that, when it gains focus, 'pack forgets' one 
frame of widgets and packs a different frame of widgets. When it loses 
focus it does the opposite (think: context-sensitive toolbar).

If I click in the entry, the other set of widgets shows up fine. The 
problem comes when I then click on another app, which causes my app to 
lose focus and go into the background. This causes the frames to swap 
due to the FocusOut binding and everything gets the "background" state. 
So far, so good.

However, when I again click in the entry which brings my app to the 
front and sets the focus, all the tile checkbuttons have a state of 
"background" even though it is the front-most app (and thus, appear 
dimmed, yet still enabled). Adding ".button state {}" doesn't seem to 
have any effect.

Does this ring any bells? Currently my <FocusIn> proc looks something 
like this:

   proc focusIn {} {
     place .sb ...
     raise .sb
     .sb state ""
     foreach w [pack slaves .sb] {
       $w state ""
     }
   }

Re: [Tile-dev] creating mega-entry (search) widgets?

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

Michael Kirkham wrote:
> On Sun, 18 Jun 2006, Jeff Hobbs wrote:
> 
>> That looks about right.  I don't suppose you would be willing to share 
>> the magic without me code-diving?  I would be willing to examine it 
>> and attempt to rationalize a more flexible variant for others.
> 
> This is the proc that does it (which may or may not be the right way to 
> do it).  It creates a "SearchEntry" layout in all themes:

As promised, attached is a megawidget variant of Michael's SearchEntry. 
  It's for placement in my tklib widget package, so it uses that 
framework (which basically means it is a snidget).

I've attached the code, with a sample.  It has a built-in image which I 
plan to modify (add a little down arrow).  The image isn't configurable 
... it's easy if I allow it across all instances (modify the master 
image), but for each menuentry will be trickier.

It's a bit of a hack of various bits together, but it does seem to work. 
  Comments welcome.  You'll likely find this in my widget package in CVS 
tomorrow.

Jeff

Re: [Tile-dev] creating mega-entry (search) widgets?

[Michael K. <mi...@mu...>]

On Sun, 18 Jun 2006, Jeff Hobbs wrote:

> That looks about right.  I don't suppose you would be willing to share the 
> magic without me code-diving?  I would be willing to examine it and attempt 
> to rationalize a more flexible variant for others.

This is the proc that does it (which may or may not be the right way to do 
it).  It creates a "SearchEntry" layout in all themes:

proc setupThemes {} {
     foreach theme [style theme names] {
         set pad [style theme settings $theme {
             style default TEntry -padding
         }]

         switch -- [llength $pad] {
             0 {
                 set pad [list 4 0 0 0]
             }
             1 {
                 set pad [list [expr {$pad+4}] $pad $pad $pad]
             }
             2 {
                 foreach {padx pady} $pad break
                 set pad [list [expr {$padx+4}] $pady $padx $pady]
             }
             4 {
                 foreach {padx1 pady1 padx2 pady2} $pad break
                 set pad [list [expr {$padx1+4}] $pady1 $padx2 $pady2]
             }
         }

         style theme settings $theme {
             style layout SearchEntry {
                 Entry.field -children {
                     SearchEntry.icon -side left
                     Entry.padding -children {
                         Entry.textarea
                     }
                 }
             }

             style configure SearchEntry -padding $pad
             style element create SearchEntry.icon image
                 $::icons::i16(search) \
                 -padding {10 0 0 0} -sticky {}

             style map SearchEntry -image \
                 [list disabled $::icons::d16(search)]
         }
     }
}

--
Michael Kirkham
www.muonics.com

Re: [Tile-dev] creating mega-entry (search) widgets?

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

Michael Kirkham wrote:
> Yes, but it's not configurable and just aesthetic, not functional.  
> i.e., they all have the same icon, and not set up to bring up a menu if 
> you click on the icon, etc.
> 
> http://www.muonics.com/Products/MIBSmithy/imgs/snmpwalk.png

That looks about right.  I don't suppose you would be willing to share 
the magic without me code-diving?  I would be willing to examine it and 
attempt to rationalize a more flexible variant for others.

Jeff

> On Sun, 18 Jun 2006, Jeff Hobbs wrote:
>> Has anyone managed to create a mega-entry widget that puts additional
>> items into the entry widget itself?  Examples are the ever-present OS X
>> search entry, and the Firefox address-bar icon+url widget.  Note the OS
>> X search widget is also rounded on the sides.

Re: [Tile-dev] creating mega-entry (search) widgets?

[Michael K. <mi...@mu...>]

Yes, but it's not configurable and just aesthetic, not functional.  i.e., 
they all have the same icon, and not set up to bring up a menu if you 
click on the icon, etc.

http://www.muonics.com/Products/MIBSmithy/imgs/snmpwalk.png

On Sun, 18 Jun 2006, Jeff Hobbs wrote:

> Date: Sun, 18 Jun 2006 10:52:31 -0700
> From: Jeff Hobbs <je...@ac...>
> To: tkt...@li...
> Subject: [Tile-dev] creating mega-entry (search) widgets?
> 
> Has anyone managed to create a mega-entry widget that puts additional
> items into the entry widget itself?  Examples are the ever-present OS X
> search entry, and the Firefox address-bar icon+url widget.  Note the OS
> X search widget is also rounded on the sides.
>
> Jeff
>
>
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>

--
Michael Kirkham
www.muonics.com

[Tile-dev] creating mega-entry (search) widgets?

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

Has anyone managed to create a mega-entry widget that puts additional 
items into the entry widget itself?  Examples are the ever-present OS X 
search entry, and the Firefox address-bar icon+url widget.  Note the OS 
X search widget is also rounded on the sides.

Jeff

[Tile-dev] lots of unusual runtime warnings on mac

[Bryan O. <oa...@ba...>]

Has anybody seen these before? I haven't taken the time yet to make a 
small reproducible case, but they happen consistently during startup of 
my application. I get the following output repeated several times over:

CGContextResetClip: invalid context
CGContextIsPathEmpty: invalid context
CGContextAddRect: invalid context
doClip: invalid context
CGContextSetRGBFillColor: invalid context

Initial experimentation shows I get this for every label or ttk::label 
widget that has a -width option. When I remove the -width option the 
warnings seem to go away. And once my app fully initializes, the problem 
seems to go away.

This is with a 8.5a4 build of tclkit for aqua; I don't remember exactly 
*which* build of tclkit, I didn't build it myself but grabbed it off the 
net, probably JCW's site.

Re: [Tile-dev] treeview hidden columns

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

Bryan Oakley wrote:

> * allow the special cases of #all to mean "all data columns" and #none
> to mean "no data columns".

I like this idea.

> The default of "-display columns {}" is
> synonymous with "-displaycolumns #all" for backward compatibility, or it
> could be synonymous with "#none" if we can eschew backwards
> compatibility if favor of something that seems a tad more logical.

Or, we could make the default "-displaycolumns #all".

Interpreting '-displaycolumns {}' the same as '#none' would
be a minor incompatibility, but I think it's worth doing.
The current interpretation of '-displaycolumns {}' is
mainly so that the widget does something sensible if
the user _doesn't_ explicitly set '-displaycolumns'.



--Joe English

  jen...@fl...

Re: [Tile-dev] treeview hidden columns

[Bryan O. <oa...@ba...>]

Joe English wrote:
> I can think of a couple solutions: (a) Extend the "-show" option
> with a third option; "-show {tree headings columns}" would be the
> new default value, and "-show tree" (or "-show {tree headings}")
> would hide all columns; or (b) make -displaycolumns have a NULL
> default value, interpret NULL as "show all columns" and the empty
> list as "show no columns".

Brainstorming here...

* make the special case of "-displaycolumns {#0}" mean "only show the 
tree column, not the data columns".

* treat {} as null, {<whitespace>} as an empty list. So, I could do 
"-displaycolumns { }" to get the empty list.

* allow the special cases of #all to mean "all data columns" and #none 
to mean "no data columns". The default of "-display columns {}" is 
synonymous with "-displaycolumns #all" for backward compatibility, or it 
could be synonymous with "#none" if we can eschew backwards 
compatibility if favor of something that seems a tad more logical.

Re: [Tile-dev] treeview hidden columns

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

Joe English wrote:
> (a) is not backwards-compatible (existing programs that specify
> both "-show" and "-columns" would need to add "columns" to the
> -show list), and (b) is a Bad Idea (there's no way for scripts
> to specify a NULL value).

We could do like the core does with [bind] or [wm protocol] and make it
so that the empty string goes to NULL but any non-empty string that is
still equivalent to the empty list goes to the empty list (I think there
are better examples too, but I can't think of them right now). Slightly
tricky, but valid.

Donal.

Re: [Tile-dev] treeview hidden columns

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

Bryan Oakley wrote:

> It seems impossible to create a treeview that has one invisible data
> column. Or am I missing something?
> [...] this gives me two columns with two visible (the tree column and one
> data column)
>
>    ttk::treeview .tv2 -columns {foo} -displaycolumns {}
>
> That is because a -displaycolumn that is the empty string is synonymous
> with "show all rows". It seems to be impossible to have a condition
> where you want none of the data columns visible.

Apparently not; this was an oversight.

I can think of a couple solutions: (a) Extend the "-show" option
with a third option; "-show {tree headings columns}" would be the
new default value, and "-show tree" (or "-show {tree headings}")
would hide all columns; or (b) make -displaycolumns have a NULL
default value, interpret NULL as "show all columns" and the empty
list as "show no columns".

(a) is not backwards-compatible (existing programs that specify
both "-show" and "-columns" would need to add "columns" to the
-show list), and (b) is a Bad Idea (there's no way for scripts
to specify a NULL value).

Any other ideas?

(On a related note: if it does become necessary to make a
backward-incompatible change, there's one more I'd like to
make at the same time: right now there's no easy way to
distinguish a child of the root element from a detached
item; [$tv parent $item] returns {} for both cases.)


> I discovered that I can add an item and give it values for more columns
> than it  has configured, though I'm wondering if that's a feature or a bug:
>
>     ttk::treeview .tv3 -columns {}
>     .tv3 insert "" end -values {"hidden value"} -text "visible value"
>
> Is it kosher to be able to supply more values than there are columns? I
> see no other way to get the desired effect.

That behavior isn't explicitly documented, but it will work.


--Joe English

  jen...@fl...