[sugar] keyboard bindings for buttons and palettes

[Tomeu Vizoso]

On Tue, Feb 26, 2008 at 3:35 PM, Marco Pesenti Gritti
<mpgritti at gmail.com> wrote:
> On Tue, Feb 26, 2008 at 8:06 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>  > Hi,
>  >
>  >  have been thinking a bit about the best way to add key bindings
>  >  (accelerators) to activities and the shell, and have come up with a
>  >  proof of concept patch at:
>  >
>  >  http://tomeuvizoso.net/~tomeu/accelerators.patch
>  >
>  >  For adding a Ctrl-B accelerator to the Back button in browse, we would
>  >  need to change the code in the following way:
>  >
>  >  -        self._back = ToolButton('go-previous-paired')
>  >  -        self._back.set_tooltip(_('Back'))
>  >  +        self._back = ToolButton('go-previous-paired', _('Back'), _('<Ctrl>B'))
>
>
>  I think we should use gobject properties here (which will still allow
>  to pass them to the constructor).

Ok

>  >  The good:
>  >
>  >  - The labels and accelerators are set at the same time so they will
>  >  appear related when translating. Every language team can set its own
>  >  policy regarding accelerators.
>
>  I'm not sure translatable accellerators are a good idea. I see the
>  advantages, but it also means you are "screwed" if you switch
>  language. Eben?

Me neither, that's why I left it at the discretion of the language
administrators. I think that errors in translating labels can be as
bad as in accelerators.

I can see how some languages may prefer to not translate accelerators.
But I guess for some languages/keyboards, the english accelerators can
be suboptimal.

Perhaps unmadindu or someone else involved in localization can give
their opinion? (cc'ing to the localization ml).

>  >  The bad:
>  >
>  >  - Every widget will have to listen for 'hierarchy-changed' in order to
>  >  set the accelerator for the group of its top level window.
>  >
>  >  Can anybody think of a better way to do this? If not, I'll come with a
>  >  more refined patch and will ask for review. I think accelerators can
>  >  improve usability quite a bit.
>
>  Nothing short of adding this functionality to gtk.
>
>  We have already a bit of duplicated code between the ToolItems,
>  perhaps we can figure out a way to avoid duplication which doesn't
>  require inheritance.

The only option seems to me to be using utility functions :/

But if the duplicated code doesn't contain much logic, perhaps we can
live with that.

Tomeu