Thanks for the reminder! I sent a message to the list asking
people to hit "escape" when the combo grabbed the focus, but it
had been a long couple of months since I'd heard "tab" was the
fix, and mixed them up.
> This is simular to another point I wanted to make a while back. on those
> combo boxes, you should allow the user to type in the values that they want.
> I don't know how the keys are redirected right now (under gtk+), but when the
> user clicks on the textbox control within the combo box, the main window
> should not capture all the keys.
Yeah, if we were doing GTK event routing the normal way, we'd just
give our main drawing area the ability to assume key focus, and
release it when some other widget gains it (for example, the combo
boxes in the toolbars). This conflicts with the user's assumption
that (in a word processor) the main window will always turn keystrokes
into document characters. We did this long before we had toolbars,
let alone combos in them.
Someone should fix this. If you look at the XAP Unix frame code,
(abi/src/af/xap/unix/xap_UnixFrame.cpp) XAP_UnixFrame::_fe::key_press_event
has some simple simple key routing code. You'll notice an--ahem--
special exception for GDK_MOD?_MASK (alt, usually) to let GTK process
the event in addition to the chars we're putting in the document.
This lets GTK use alt-key combinations for the menus.
I'm not sure if the logic in that function is right. Specifically,
I don't think the "gtk_signal_emit_stop_by_name()" is needed at
all.
> Some of the combo boxes should limit what's typed to just list items, i.e.,
> fonts, while others you want to type your own-style, font size, zoom, ...
This would just require some changes to the main window's key handling.
One solution would be to handle a rudimentary focus grab on the main
window. You'd want to check with the Win32 implementation to see if it
already does something like this.
I see two solutions to this general problem:
SOLUTION 1
1. GTK brokers focus through focus_in and focus_out events.
The combos already throw these on click, and one can't type
in them without focus. Our problem arises from not being able
to lose focus on the combos, which happens automatically
when another widget claims it.
2. GTK's drawing area (our widget for our document area)
doesn't automatically claim its focus on click.
If we made it do so, we'd solve our problem, but we'd
introduce another. The user would have to click back into our
document to start typing there again. We'd have to put
a little exception in there somewhere (like when the
combo just set its contents into action) to lose its
focus and give it to the main area.
3. There's a little investigation into how to be able to
grab and release focus as a GTK widget.
SOLUTION 2
1. This solution is more of an immediate one that doesn't
include making the top-level drawing area widget claim/release
focus.
Stick a UT_Bool in the Unix frame class to hold UT_TRUE
whenever a widget needs to have its focus. Whenever
this value is UT_TRUE, all keystrokes are ignored by
the frame key handler (pUnixKeyboard->keyPressEvent() is not
called).
2. Whenever a combo grabs focus, it tells the frame (which
sets its variable). Any keystrokes that happen now go only
to the combo.
3. Whenever a combo is done doing its thing (like when its contents
are applied to the document formatting after an "enter" or
after a cancel with an "escape"), it (1) throws its
gtk-recognized focus (2) tells the frame to accept keys again.
Anyone want to do this one? Kind of a combination bug fix/new feature.
-- Shaw Terwilliger