Menu
▾
▴
tktable-tile-dev
|
From: Bryan O. <oa...@ba...> - 2006-06-23 22:12:09
|
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 ""
}
}
|
|
From: Bryan O. <oa...@ba...> - 2006-06-23 22:29:10
|
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.
|
|
From: Vince D. <vin...@gm...> - 2006-06-24 22:08:17
|
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. |
|
From: Joe E. <jen...@fl...> - 2006-06-27 21:04:17
|
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
|
|
From: Vince D. <vin...@gm...> - 2006-06-27 21:52:20
|
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. |
|
From: Joe E. <jen...@fl...> - 2006-06-30 21:26:35
|
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...
|
