Re: runtime accel changes

On Thu, Sep 13, 2012 at 11:01 PM, Paul Davis <paul linuxaudiosystems com> wrote:
> On Thu, Sep 13, 2012 at 4:43 PM, Juan Pablo Ugarte
> <juanpablougarte gmail com> wrote:
>> On Thu, 2012-09-13 at 06:22 +0000, Tristan Van Berkom wrote:
>> > 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
>> > gtk_action_group_add_action_with_accel()).
>> >
>> > 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 ?
>> I do not know about deprecating it, but we could definitely have a
>> default accelerator group that gets set in every window and action group
>> by default. This way actions will simply work and if for some reason you
>> need a window with a different accel group you can always set it later.
>> I like to keep common cases simple and special cases well special. :)
> fundamentally, what differs from window are the available actions. the fact
> the accels per window *might* be different is just a side-effect of this.
> therefore, action groups are the primary entity that needs to be attached to
> a window, not accel groups.
> since currently neither action nor accel groups permit sharing of actions or
> accels, both concepts are pretty useless in GTK right now. most applications
> end up with a single action group (semantically, anyway) and a single accel
> group. and if they don't they probably meant to :)

For accel groups I agree with you, but action groups are not useless.
For example you can have an action group that gets enabled/disabled
depending on whether something is on the clipboard (containing all
sorts of paste actions) or one that is only enabled when items are
selected (containing copy, cut, reformatting actions, etc.) I'm not
sure what you mean by semantically a single action group, but I don't
think that's it.

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