Re: keypresses and embedded components WAS: Re: gnome-vim

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-09-05 at 14:20, Jason Hildebrand wrote:
> > 2.  If it's not usable now, is there any hope that the GTK
> >     design can be fixed up to support more localized control
> >     of keystrokes?  (It seems to me that virtually every system
> >     I've looked at has a way to delegate the interpretation of
> >     keystroke events to the component that has the focus.
> >     Otherwise you have to design around the unknowable conventions
> >     that the containers happen to choose.)  It seems to me it's
> >     not enough to have a good idea for what to do--you have to get
> >     buy-in from the main-line GTK implementors, don't you?
> 
> Bingo.  I have to convince the GTK maintainers that this is the right
> way to go.  I chatted with Owen Taylor about this issue on irc a few
> months ago, and he seemed to suggest that GTK's keypress event model
> doesn't support what I want to do (and wasn't about to change).
> 
> I don't blame him, though, since I don't think I fully explained the
> problem and wasn't able to make clear that this is not a vim-specific
> problem.  I've since discovered that the Galeon team has encountered the
> same problem embedding Mozilla
> (see http://galeon.sourceforge.net/links/interview_2003-07.php, search
> in page for "typeaheadfind").

Oh, no, I didn't have any problem *understanding* your problem. But
I still don't believe that the embedding shell eating Escape is anything
but a bug in the embedding shell. (On the other hand, there may well
be other VIM keybindings that are simply incompatible with embedding
in a modern UI. As a hypothetical example, F10 must *always* pop
up the menu bar. It can't do something else because a VI widget is
focused.)

> I believe components _need_ to get first crack at handling all
> keypresses when they are focussed -- even key events which the embedder
> uses as an accelerator -- but for this to work they need to pass
> unhandled keypress events back to the embedder.  In fact, the XEmbed
> protocol spec, written in part by Owen, even goes so far as to suggest
> this last point:
> (http://www.freedesktop.org/standards/xembed-spec/0.5-html/ar01s07.html#id3314664).
> (the GtkSocket/GtkPlug widgets are the foundation upon which bonoboui
> components are based, and they are an implementation of the XEmbed
> spec).

You are misreading that; I'm not talking about changing accelerator
handling there, but simply about what happens to keystrokes that get
past accelerator handling.

> I think the next logical step is for someone (me, I guess, since it's
> primarily my itch at the moment) to code this up and see if it works and
> whether it can be done in such a way as to not break existing apps using
> GtkSocket/GtkPlug (which includes all bonobo components).  

The next step you'll have to take is to suggest a change to the XEMBED
spec on xdg-list freedesktop org  Assuming that your goal is to get
changes into GTK+.

If you want a more convincing use case than embedding VIM, you can look
at the problems people have with XIM based input methods, which also
tend to want keystrokes that conflict with menus.

See: http://bugzilla.gnome.org/show_bug.cgi?id=90082 and discussion
in the last few days on gtk-list.

Regards,
						Owen