Re: runtime accel changes

On Wed, Sep 12, 2012 at 9:15 PM, Paul Davis <paul linuxaudiosystems com> wrote:
> On Wed, Sep 12, 2012 at 5:07 PM, Michael Natterer <mitch gimp org> wrote:
>> On Wed, 2012-09-12 at 16:27 -0400, Ryan Lortie wrote:
>> > hi,
>> >
>> > I recently wrote a patch[1] to re-enable accel labels in GtkMenu
>> > generated from GMenuModel.  They got lost in the shuffle during some
>> > related recent changes.
>> >
>> > Essentially, the new approach means that the accel='' attribute of each
>> > menuitem directly determines what the accel label will be (instead of
>> > doing the lookup in the accelgroup).
>> >
>> > The most noteworthy impact of the patch (and the topic of this email) is
>> > the strong implication that we will no longer support runtime changing
>> > of accel keys.
>> I object. Do you really want to disable shortcut editors in
>> complex applications such as GIMP? That would seriously hurt GTK+
>> as a general purpose toolkit. I can't imagine why you would do
>> such a change.
> I echo Mitch's objections. Ardour users find it very convenient to do
> runtime changes to key bindings. Requiring program restarts and all that,
> let alone the idea that bindings have to set at menuitem creation, all seems
> pretty piss poor to me.

While on the topic of accelerators, and since we have the attention of two real
user of them... I'm curious what you guys think of removing the need to use
GtkAccelGroup in GTK+ api.

>From what I see... all one should *need* to do is specify the accelerator keys
desired to trigger a given GtkAction and add that action to an action group
(either with GtkBuilder constructs or with

The fact that a GtkAccelGroup must be added to a GtkWindow... and that it must
be referred to by the GtkActionGroup (need to set the
property/relation somewhere)...
is all a bit sub-par as an API (i.e. it's confusing, not obvious to figure out).

So my basic question is... is there anything good about manually
setting up these
accel groups at all ? GIMP is an example of a multi-windowed application (and
many apps can have a 'floating' editor for some purpose)... as it
stands whenever
you create an extra floating window that is not a temporal dialog, you must set
the GtkAccelGroup manually also for those windows for accelerators to work
while those windows have focus.

GTK+ of course manages an internal list of the app's GtkWindows... I
really dont
see the reason why GtkAccelGroup couldnt just be completely automated...
could we possibly just deprecate/eventually remove that from the (public) api ?


(PS: Sorry Paul for receiving twice this mail... forgot to reply-all first shot)

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