Re: broken accelerator changes



On 2 Mar 2002, Havoc Pennington wrote:

> > so, you should actually propagate settings on demand (e.g. by pressing
> > an "Apply" button in the config dialog), once you're there though,
> > propagating accel changes doesn't require "a whole bunch of code",
> > basically you dump the accels in one instance into a string and read
> > that string back in in another application.
> 
> That makes the gconf representation unusable with
> gconf-editor/gconftool, and makes it inefficient. You need a different
> config key for each keybinding.

changing a single key may cause multiplte accel map entries to change
at once.

> > nope, it's broken to limit accelerator changes to yet another menu
> > API.
> 
> Accel changes need not be limited to a new menu API.
> 
> We can extend the accel map API to make it possible to easily write a
> more generic accel editor, at least potentially; the accel map needs
> notification of changes, and it needs human-readable names for the
> accel paths. If it had those then you could edit it directly with an
> accel editor dialog.

right, we had that in our initial version of the accel map but
decided against notification for the scope of 2.0.

> Right now notification of accel path changes involves a mess of code
> to create a fake accel group full of fake accel closures, and a
> reverse map from the fake closures to accel paths.

this aproach is uterly insane. either you hack on an accel map
editor within gtk+ and can make use of private API extensions that
way, or you don't tackle that task at this stage at all.
the current API is simply not designed for third party notification,
so don't do it.

it'd be wise to post a proposal for an implementation before starting
out on one anyways, there's a slight possibility of you getting input
about how to aproach certain things you might not get otherwise, and
it raises the chance of ending up with a sane implementation that
can actually get backfolded into gtk at some point.

> 
> Havoc
> 

---
ciaoTJ




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]