Re: [Evolution-hackers] Found key binding bug, need hint!

[Not Zed <notzed ximian com>]

On Sun, 2005-07-03 at 09:46 +0200, Roland Orre wrote:
> I found a bug in key bindings for evo 2.2.1.1 but I don't know
> how to fix it, and I need som hint on how things are glued together.
> 
> I also tried to report on bugzilla, but found that the bug was already
> reported in Nov (http://bugzilla.gnome.org/show_bug.cgi?id=269404)
> and there were other related reports like 150059, 259331 and 232441,
> still not fixed, which urges the need to do someth.
> 
> The bug is that emacs key bindings (after my last upgrade) only works
> in about 50% of the cases for the first composed email after each new
> invokation of evolution. In the following they are not working at all.
> This must be a problem in evolution, probably in message-tag-followup.c
> but I'm not experienced enough with gtk to tell. This simply means I
> can't use evolution any more if I'm not able to fix this.

Well it simply means you find it too difficult for you to use.  It
doesn't mean you can't use it; dont overstate the problem.

message-tag-followup.c couldn't possibly be related to keybindings, at
all, let alone the composer specifically.  It is an unrelated blob of a
feature that only interacts with a very limited part of displaying
messages.

Most of the keybinding stuff is internal to gtk+.  But gtkhtml, the
editor widget used by evolution obviously must do some of its own
interpretation of keys too.   Although to be honest, in 5 years of using
evolution daily, i have never once seen it not operate as set - the
binding isn't very complete, but then it is impossible to do a full
emacs binding without modal/command line input.

> The fundamental bug is obviously an evo one, but the related problem
> may be a general gtk one. For now there are only two options in gtk,
> either use the default weird windoze inspired keys or emacs style, but
> what about other preferences like vi? This interface needs to be made
> more general.

> For every programmer keybindings are essential, I'm an emacs user and
> have used different flavours of emacs (Amis, Multics emacs, Gosling emacs,
> Gnu emacs) during my 25 years of hacking.
> I'm using emacs keys with openoffice, that works fine. I even used emacs
> keybindings in MSWord, when I used that for a while around 1990 on a
> Mac at the university.

I'm a programmer too, i dont find it much of a challenge to change what
keys i use based on the software i'm using.  Or an ir remote for a tv,
or different door knobs for that matter.  I use vi and less many times a
day, live in emacs, and use the evolution editor all the time too.  I
use them all differently based on their interfaces without even thinking
about it.

> In the Gnome environment emacs key bindings usually work fine,
> like now in Firefox when I'm writing this with gmail, although in some
> applications, like thunderbird, the application "steals" keys which can
> cause very annoying behaviours, this needs to be fixed as well.

> Obviously evolution does some weird things with the keys as the
> keys don't work at all in the composer header. Apart from when
> I get a meny, like when having several destinations to choose from,
> then the emacs key bindings are suddenly working again in the
> header.

Well, this may not be related directly to evolution as such, again each
widget is a separate object, which may have different bindings or
different binding bugs.

> Apart from the evolution problem I assume that gtk keybindings may
> need some fresh up. The way e.g. thunderbird does is unforgivable
> and reminds me about the old MSDOS... When I pressed ^P there
> I was asked about printer. The same as in the old DOS if you accidentaly
> hadn't loaded the dosedit environment with proper emacs keys.

I guess you'd better ask the gtk guys about that.

> For applications that include key settings options (like openoffice and
> evolution in release 1.0) it seems not to be a problem, but in applications
> that rely on a proper gtk key behaviour problems arise, if the applications
> them self lock some keys in.
> 
> Anyway, the urgent thing is to fix keys in evolution. If someone has
> a hint I'm grateful.

For the composer body, try grepping for "Key" in gtkhtml/src/* (in the
gnome cvs).  For the composer 'to' area, i think that is somehwere in
evolution/addressbook/select-names or something to that effect.  For the
subject area, i think that is just a GtkEntry - look in gtk
+/gtk/gtkentry, or maybe it is an EText, try gal/gal/e-text or
evolution/widgets/ or something on the CVS trunk.

Since the binding setting appears to be intermittent, its probably some
race/bug reading the setting from gconf, or as in the bug report above
the gconf key has changed.  i.e. if the code wasn't there to do it it
would never work so the code must be there.

Also, things in the menu's can't be overriden.  e.g. ctrl-p will
activate the print menu.  A couple of reasons for this, one is that the
middleware we're using - bonobo - wont let us, and another is that
customisable menu bindings are generally thought of as a bad ui idea
anyway - one of the few things in the gnome ui guidelines i'd probably
agree with.