Subject: Re: commit -- fixed #522
Date: Tue Feb 08 2000 - 22:17:55 CST
Daniel Weber wrote:
> Is the patch committed? I'd like to see what you changed. I've spent
> the last hour mucking with the toolbar text boxes and I'm amazed how
> many times the handler gets called. On my system, a blue box (usually
> focus) is around the box forever (or until you click on another one) and
> a lot of keys, numlock on or no, trigger the handler for selection
> changed. The '-' key and backspace in particular. But clicking
> anywhere in the text gets it too. Strangely enough, selecting a zoom
> change causes a selection change event in all the boxes, while changing
> to header one only triggers header and font.
Yes, we do have focus problems--namely, we don't actually keep track of
focus in the top-level window. This problem affects all platforms, since
part of the solution is a cross-platform policy, but some platforms that
contain GUI elements that do things very independently (like GTK, whose
widgets provide tons of default features) have problems.
> I'd just convinced myself something deep and strange was going on - Ill
> be glad to be corrected....
Something deep and strange is going on. :) I haven't traced the
"deep and strange" path entirely, but the drop-down boxes are taking
focus when they're clicked on (or something from them is selected),
and they never relinquish focus (save for a "tab" key pointed at them).
The problem is that when AbiWord's frame gets a key press, it handles it
(through the edit methods), and then passes on the key if and only if
it's an ALT key (so that GTK can handle all those menu hot-keys, like
"Alt-F" for File menu, etc.).
When we pass keys through that have "num lock" on (MOD5), GTK passes
that key press down to the focussed toolbar combo box, and it drops.
My changes are detailed at:
My solution simply catches MOD5 as something we should block, like most
other key presses.
-- Shaw Terwilliger
This archive was generated by hypermail 2b25 : Tue Feb 08 2000 - 22:17:55 CST