[sugar] keyboard bindings for buttons and palettes
Fri Feb 29 08:14:53 EST 2008
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).
> > 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
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.
More information about the Sugar-devel