Re: broken accelerator changes

[Tim Janik <timj gtk org>]

On 2 Mar 2002, Havoc Pennington wrote:

> 
> Hi,
> 
> I'm already having to massively hack around the accel thing because it
> doesn't work right for gconf apps; all the other settings in the new
> gnome-terminal propagate across all gnome-terminal processes, but 
> the accel changes do not. So I'm needing to write a whole bunch of
> code to hook it up to gconf instead of saving to a file so I can keep 
> the in-place accel editing working while still offering a nice dialog
> UI for changing accels that applies across all app instances.

it's not a good idea to have all keypresses propagate directly to all
applications of that same type, as you might have temporary state in
changing things here which you wouldn't want to propagate immediately
(kinda like when editing an entry).
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.

> With the new menu API we want to see for 2.2 or 2.4, we'll be able to
> offer a generic KeyEditor widget either in GTK or in libgnomeui, that
> will be based on TreeView. This will automatically cover all menu
> items for all apps using the new menu API since it will let you change
> the accels for any of the "actions" as in jhmenu. That's the right
> solution to this problem.

nope, it's broken to limit accelerator changes to yet another menu
API. while the action abstraction james' gmenu is basically the
right thing to do, there's no reason to suport changable accelerators
only for that menu that go through the new API. it's just another
application of the accel map, and accel editing dialogs should change
things directly in the accel map.

> But bottom line: GNOME UI team wants it off so gnome-settings-daemon
> will disable it via XSetting probably, and I can tell you it is going
> to be off in the Red Hat RPMs.

gnome can have it's own default within some session wide configuration
mechanism like the control center. it's pretty poor your going to disable
this for RH RPMs though, as stated earlier, non-US users often _have_ to
change accels for them to make sense, ignoring that fact is just stubborn
blindness to demands of users of other countries.

> writing embedded or kiosk sort of applications, etc. - and these are
> the kind of people that usually write to gtk-list and think this
> feature is a bug.

kiosk style apps are the exact reason why there's API to disable
accel changing by API. here, you usually can forsee the exact area
of deployment and setup things accordingly.

> 
> Havoc
> 

---
ciaoTJ