* I have a ttk::notebook with two tabs.
* Each tab contains a text widget and a scrollbar.
* I click in the text widget giving it focus.
* I click on the other tab. The other text widget is now in view. It
does not have focus.
* I type a sentence.
* The characters end up in the text widget on the first tab.
In other words, a widget which isn't even visible has the focus, and
is responding to keyboard events. I'd have thought that when I
clicked on the other tab, the text widget on the first tab would lose
the focus.
Is this expected behavior? Is it a bug?
That is not expected behavior, definitely a bug, should
not happen. (What should happen: when you select a new tab,
the first traversable widget in that tab should take focus.
If you reselect the already-selected tab, the notebook itself
claims focus. You can't see this on OSX, but on Windows and X11
there is a focus indicator on the tab.)
Can't replicate (it works as intended under X11 and Tk8.4+Tile
under OSX 10.4; I don't have access to a Leopard system), but it
would not surprise me at all if something in TkAqua changed with
Cocoaification that breaks the (admittedly fragile) ttk::notebook
focus logic.
Could you file a bug report at SourceForge?
--Joe English
Certainly; but as I'm using 8.5.8, I believe I'm still using the
Carbon version. Not so?
Am able to replicate with the script attached to the bug report.
Turns out this is not Carbon/Cocoa related after all, it's a
cross-platform bug.
Working on a fix now. As an interim workaround, you can
specify "-takefocus 1" on the contained text widgets.
(Cause of the problem: [ttk::focusFirst] mistakenly assumes
that all widgets have a nonempty "-takefocus" option; this
is true for all ttk::* widgets, but not for core widgets
and those from other widget sets.)
--Joe English
Thanks, Joe!