Subject: Re: focus (was Re: Bug 435 - accents only work after font change)
From: Aaron Lehmann (aaronl@vitelus.com)
Date: Fri Mar 24 2000 - 01:27:35 CST
Paul,
I think GTK's focus model where any control can have focus is inherently
flawed. I think that only editable items should have a concept of focus
(As you can probably tell, I don't believe in keyboard-driven GUI's). I
think it would be good if at least on UNIX the main text are would always
have focus unless a control in the toolbar was being used. I am not sure
how hard this is to do since I am currently very confused about the way
AbiWord handles this... If you click on an entry of a combo box, a small
focus rectangle appears inside it and suddenly the multi_key starts
magically working. My uninformed guess is that the combo box really has
the focus but AbiWord is connecting to keyboard events on the main window
and doing its own (simple) focus handling, independently of GDK. I don't
think that this is a good thing. I would love to look into this further
and fix these issues except for the fact that I have a trip coming up soon
so it might be a few weeks... although I would be pleasently suprised if
the CVS already had improvements when I came home.
As for configurable keybindings, I don't think this would be a big
deal with GTK. If the focus is done right, (i.e. the text area always has
focus unless something is being used in a toolbar) then the key-press
signal could be connected to the text area's class rather than the
frame's. One thing to consider here is wheter there will be any items in
the window (toolbar items, status bar item, etc) that will need to have
keyboard focus. Right now there don't seem to be, but if we want to
accomodate these we should design the focus system accordingly.
Please be aware that focus handling is not what I am really complaining
about. I think AbiWord's focus system works fine right now, even though it
is kludgy, except for the fact that it seems to be causing GDK to return
wrong keypresses for accented characters. Presumably this is because it is
making assumptions about the focus of the window that AbiWord violates by
doing its own focus handling (e.g. it might look to GTK like no widget has
focus, and if that is true, why bother returning correct key presses?).
This is either a bug in GDK or an annoyance. Either way, it should be
possible to work around it by quickly hacking the focus system in AbiWord
to make the focus that GTK sees parallel the internal focus that AbiWord
has set. I'm instested in hearing whether you think this should be worked
around or that the focus managment system is in need of replacement
anyway.
Aaron Lehmann
P.S. This is all based on observation and tedious reading of the code. I
may be wrong. Perhaps it doesn't have anything to do with focus at all,
although that seems like the most likely reason to me.
On Thu, 23 Mar 2000, Paul Rohr wrote:
> Aaron,
>
> A quick response for you.
>
> 1. The reason we do keyboard handling at the toplevel window is to allow
> the configurable keybinding mechanism to work. Keystrokes may come in for
> command-key accelerators and/or for typing into the document. The important
> thing is to have all of the keyboard events wind up in one central place for
> processing. Doing so in XAP code is ideal, because the resulting XP
> mechanism will then be available for any application using our framework.
>
> If you wind up deciding to move focus to one of the child widgets, then
> you'll need to make sure that attempts to send focus elsewhere inside the
> top-level container are forwarded appropriately.
>
> 2. However, we definitely *do* need to do a better job of integrating what
> we do with platform-specific notions of focus, even if we just use the
> normal focus mechanisms as a filtering cue for simulating the desired
> behavior. For example,
>
> - we should know when to claim and give up the focus (and then do so)
> - we should ignore keyboard events when we *don't* have the focus
> - we shouldn't draw selections or blink the cursor then either
>
> There are probably more details I'm forgetting, but I wanted to confirm that
> this *is* a real problem that could use a good solution. If you'd like to
> team up with folks on the various platforms to spec what the desired focus
> *behavior* should be, that'll take care of the hardest part.
>
> By comparison, once you've got those details spec-ed out, getting that
> behavior implemented shouldn't be that bad.
>
> Paul
>
This archive was generated by hypermail 2b25 : Fri Mar 24 2000 - 01:27:44 CST