TkTable / Tile / Vu

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.

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

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

On 6/27/06, Joe English <jenglish@...> 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.

Vince Darley wrote:
> On 6/27/06, Joe English <jenglish@...> 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

  jenglish@...

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

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/

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

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 <jeffh@...>
> To: tktable-tile-dev@...
> 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
> Tktable-tile-dev@...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>

--
Michael Kirkham
 http://www.muonics.com

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.

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
 http://www.muonics.com

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

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

  jenglish@...

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