keypresses and embedded components WAS: Re: gnome-vim
- From: Jason Hildebrand <jason peaceworks ca>
- To: "Jeffrey A. Scofield" <jeff dhitechnologies com>
- Cc: gnome-components-list <gnome-components-list gnome org>, gtk-devel-list gnome org
- Subject: keypresses and embedded components WAS: Re: gnome-vim
- Date: 05 Sep 2003 13:20:48 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]