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

[Jason Hildebrand <jason peaceworks ca>]

On Fri, 2003-09-05 at 13:53, Owen Taylor wrote:
> 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.

Hi Owen,

The thing is that the shell doesn't necessarily know which component it
will be using -- the actual component invoked could be user-configurable
(think pluggable editors, in the case of gnome-vim).  Because of this,
it may be perfectly reasonable for the shell to eat Escape for one
editor, but unacceptable for another.  If the component passes back the
unhandled keystrokes this problem is solved, but I wanted to point out
that eating Escape is not necessarily a bug in the 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.)

Agreed - this is something us vi users will just have to live with.

> > 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.

Sorry, I wasn't trying to misrepresent anything -- I was only referring
to the last part of my sentence (i.e. passing unhandled keystrokes back
to embedder); I didn't mean to imply you wrote anything about
accelerators.  

Changing accelerator handling would indeed be a significant departure
from the current spec, and is a separate issue from the
pass-back-unhandled-keystrokes issue.

> > 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+.

Thanks for pointing me in the right direction.  I think I'll code it up
first, though, because I'll feel more confident proposing a change after
doing a proof-of-concept.

> 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.

Thanks for the tip.  I'll check it out.

peace,
Jason