Re: Patch for Delete key behavior (for dia-0.96.1)

[Ondrej Mikle <ondrej mikle gmail com>]

Hans Breuer wrote:
> On 22.09.2007 00:42, Ondrej Mikle wrote:
> > I send a patch for the Delete key behavior in Dia. It is remapped to
> > Ctrl+Delete (or remap it some other suitable shortcut), since a lot of
> > people find it annoying that pressing Delete while editing text deletes
> > the object.
> Indeed differnt people have tried to fix this problem ;) In Dia's stone age
>  deleting objects was bound to Ctrl+D for exactly this reason. Than the
> more natural Delete key was used giving us the described regression.
> But falling back to some other 'random' hotkey for deleting objects is not
> the right solution, just a workaround.
>
> The real fix would be some managment of text edit mode, where all the
> usuful keys (not only Delete but also cursor keys, Home, End) are bound to
> text editing as one is used by other programs.
>
> This extra mode - maybe shown and selectable by a cursor button in the
> toolbox - would allow us to distinguish between object editing, where these
> keys are used for diagram modification.

OK, I see. I've tried to create code which detects text editing mode and
acts differently when some text has focus. It works via installing a
keyboard snooper (gtk_key_snooper_install), which is run before the key
is passed to the accelerator handling. The key snooper checks, if the
key is one of the text editing keys (Del, ...), if some canvas have
focus and if some text has focus (via ddisplay_active and active_focus)
and either passes the key down or calls handle_key_event.

However, clicking on an object with text in it changes it immediately to
text editing mode. So user wouldn't be able to delete it via shortcut
(only by selecting it with rectangle and then deleting), which is not
very comfortable. So I guess the best way is to let the user change the
shortcuts.

> A patch to fix the broken user editable shortcuts should give you the same
> workaround but not break the use of Delete for diagram editing for other
> users. It would have a much bigger chance for inclusion.

This is way to go. Should be easy to fix, although I can't get
gtk_accel_map_load working (the gtk manual is not very verbose and I
didn't find anything useful on the net; saving accels works). I've read
through the gtk code, but I actually can't find where gtk_accel_map_load
does the accel bindings. It does parse the file, but that seems it (gtk
2.10.13). Anyone know how to use the gtk_accel_map_load properly? Using
gtk_accel_map_change_entry works fine though, so I may have to write my
own load/save accel functions.

Cheers,
O. Mikle