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