keypresses and embedded components WAS: Re: gnome-vim
Jason Hildebrand <[email protected]> 05 Sep 2003 13:20:48 -0500
| Newsgroups | gmane.comp.gnome.components,gmane.comp.gnome.gtk+.devel.general |
|---|---|
| Message-ID | <1062786047.22973.86.camel@localhost> |
On Wed, 2003-09-03 at 15:09, Jeffrey A. Scofield wrote: > Greetings, > > I have a couple of questions about gnome-vim if you have the time. Hi Jeff, Sorry for the slow reply. I hope you don't mind my taking this opportunity (thanks for the nudge) to try to further the discussion on how to fix the keypress handling in GTK by copying this to a couple of relevant lists. > I would love to have a working vi-like editor of any kind > to use inside Evolution, so I'm very interested in the gnome-vim > project. However, the description of ``keypress conflicts'' > suggests that it can't work reasonably until GTK is revised to > support new handling of keypress events. While this is probably > the right thing to do (and in fact it suggests a serious flaw > in the current GTK design), it doesn't seem like something that > will happen any time soon. > > This leads to two questions: > > 1. Is it, in fact, possible to use gnome-vim in Evoluation at all > in its current state? I can't imagine using vi without the > ability to type the <ESC> key! No, not currently. I had this working several months ago, but it involved patching evolution (so that it didn't capture ESC). But as patching Evolution is necessary anyways to make it use a different editor component, this is probably a good interim solution. I just need to find the time to update my Evo patch (now that Evo 1.4 is out) and make it available. > 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"). 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). 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). peace, Jason