Re: runtime accel changes
On Sun, Sep 16, 2012 at 8:05 AM, Benjamin Otte wrote: > Michael Natterer gimp.org> writes: > >> I think my actual point here is: There are so many usecases >> and levels of complexity in peoples' workflows, and >> in the applications that can be written in GTK+, we should >> not disable useful things because they are either not in >> fashion any longer according to whoever defines "fashion", >> or are out of scope for some refactoring. Instead, rather >> adjust the scope of the refactoring. >> > I think this is not a very good argument. GTK is still severely understaffed > and > has such a huge complexity already that it is necessary to cut. And to cut > heavily. In particular because people expect GTK to grow even more features > (mostly in the graphics and touch departments). > > Also, there is a lot of places where developers don't really understand the > code > they are touching and the code does things in a "weird" way (read: It was > written 10+ years ago when we were all writing code differently). And when > someone actually does dare to touch these codepaths again, he'll have to make > choices - and oftentimes the choice is not 100% backwards compatibility, but > implementing desired new functionality. And I personally prefer people > reducing > the amount of unmaintained code, even if the cost to that is features. And if > it > turns out those features were great, hopefully someone will volunteer to add > them back later. I do agree and do disagree, in this particular case I think that we have code in place that does do runtime accelerator changing properly, even if I would personally like to privatise that accelmap/accelgroup stuff into some basement, we do have a good GtkAction[Group] api that at least should take care of all of this stuff automatically. There's no sensible reason to just throw that away. Some examples in contrast; for instance when we ditched code generation feature from Glade, *so many people complained* really they did, but we did it on the grounds that the feature was crap and the feature itself had more negative impact than positive. On the other hand, ... oh how I would have loved to throw GtkSizeGroup in the garbage when implementing height-for-width... based on the same arguments perhaps I should have... but it's a useful feature that already worked (read: I had not considered them properly and so I had to expand the scope of my refactoring, that was my own fault and my own responsibility) it probably cost me an extra week (maybe more) of hair pulling to get h4w apis to play well with size groups. And dont even get me started about GtkUIManager and that silly "merge ui" feature... if it wasnt for that feature and our lazyness in porting that feature into GtkBuilder proper then we would have ditched that double standard of UI building years ago. > I'm pointing this out because I don't like the way of reasoning here. I have > no > real opinion on editability of keybindings. ... I would think that anyone who has played starcraft... would have an opinion about the usefulness of configuring keybindings without restarting the application ;-) (couldnt resist). Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
Michael Natterer gimp.org> writes: > I think my actual point here is: There are so many usecases > and levels of complexity in peoples' workflows, and > in the applications that can be written in GTK+, we should > not disable useful things because they are either not in > fashion any longer according to whoever defines "fashion", > or are out of scope for some refactoring. Instead, rather > adjust the scope of the refactoring. > I think this is not a very good argument. GTK is still severely understaffed and has such a huge complexity already that it is necessary to cut. And to cut heavily. In particular because people expect GTK to grow even more features (mostly in the graphics and touch departments). Also, there is a lot of places where developers don't really understand the code they are touching and the code does things in a "weird" way (read: It was written 10+ years ago when we were all writing code differently). And when someone actually does dare to touch these codepaths again, he'll have to make choices - and oftentimes the choice is not 100% backwards compatibility, but implementing desired new functionality. And I personally prefer people reducing the amount of unmaintained code, even if the cost to that is features. And if it turns out those features were great, hopefully someone will volunteer to add them back later. I'm pointing this out because I don't like the way of reasoning here. I have no real opinion on editability of keybindings. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
On Thu, Sep 13, 2012 at 11:01 PM, Paul Davis wrote: > > On Thu, Sep 13, 2012 at 4:43 PM, Juan Pablo Ugarte > wrote: >> >> On Thu, 2012-09-13 at 06:22 +, 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. -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
On Thu, Sep 13, 2012 at 4:43 PM, Juan Pablo Ugarte < juanpablouga...@gmail.com> wrote: > On Thu, 2012-09-13 at 06:22 +, 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 :) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
On Thu, 2012-09-13 at 06:22 +, 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. :) greets Juan Pablo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
On 13/09/12 14:20, Ryan Lortie wrote: Is there a usecase for users who regularly switch keybindings as part of their normal workflow, or is this a sort of "customise the app once, then use it forever" type of situation? If you sit down at someone else's computer it is useful to be able to switch to a different set of key bindings. For example, with Matlab under Linux, the first thing I would do when taking over someone else's session is to change from Emacs-style key bindings to the Windows-style key bindings. I didn't have to close all the open models and restart for this to take effect. It was easy to revert back afterwards. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
On Thu, 2012-09-13 at 09:20 -0400, Ryan Lortie wrote: > hi, > > Thanks for the feedback. > > On 12-09-12 05:15 PM, Paul Davis wrote: > > On Wed, Sep 12, 2012 at 5:07 PM, Michael Natterer wrote: > >> I object. Do you really want to disable shortcut editors in > >> complex applications such as GIMP? > > > > I echo Mitch's objections. Ardour users find it very convenient to do > > runtime changes to key bindings. > > Is there a usecase for users who regularly switch keybindings as part of > their normal workflow, or is this a sort of "customise the app once, > then use it forever" type of situation? Both. My guess is that for most it's a change once, or adjust config gradually situation. But we regularly have people on IRC who tell us they configure shortcuts all the time, and have their current most common workflow on F1..F6 or such, or on Alt-foo bindings that are mostly unused. We even get reports from those who have gtk-can-change-accels enabled, but as said earlier, please not ;) I think my actual point here is: There are so many usecases and levels of complexity in peoples' workflows, and in the applications that can be written in GTK+, we should not disable useful things because they are either not in fashion any longer according to whoever defines "fashion", or are out of scope for some refactoring. Instead, rather adjust the scope of the refactoring. --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
On Thu, Sep 13, 2012 at 9:20 AM, Ryan Lortie wrote: > hi, > > Thanks for the feedback. > > > On 12-09-12 05:15 PM, Paul Davis wrote: > >> On Wed, Sep 12, 2012 at 5:07 PM, Michael Natterer wrote: >> >>> I object. Do you really want to disable shortcut editors in >>> complex applications such as GIMP? >>> >> >> I echo Mitch's objections. Ardour users find it very convenient to do >> runtime changes to key bindings. >> > > Is there a usecase for users who regularly switch keybindings as part of > their normal workflow, or is this a sort of "customise the app once, then > use it forever" type of situation? > for ardour, more like the latter. though probably more accurate to characterize as "continually make minor tweaks to bindings as knowledge of the app develops and workflow changes". ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
hi, Thanks for the feedback. On 12-09-12 05:15 PM, Paul Davis wrote: On Wed, Sep 12, 2012 at 5:07 PM, Michael Natterer wrote: I object. Do you really want to disable shortcut editors in complex applications such as GIMP? I echo Mitch's objections. Ardour users find it very convenient to do runtime changes to key bindings. Is there a usecase for users who regularly switch keybindings as part of their normal workflow, or is this a sort of "customise the app once, then use it forever" type of situation? Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
On Wed, Sep 12, 2012 at 9:15 PM, Paul Davis wrote: > > > On Wed, Sep 12, 2012 at 5:07 PM, Michael Natterer 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 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 ? Cheers, -Tristan (PS: Sorry Paul for receiving twice this mail... forgot to reply-all first shot) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
On Wed, Sep 12, 2012 at 5:07 PM, Michael Natterer 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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
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. "Simplification" cannot be a goal by itself if you remove useful features in the process. If it's about removing the antique feature of editing shortcuts directly by hitting a key on the menu item, then I'm all for removing the cruft. But the underlying infrastructure, please not. --Mitch > It's my personal opinion that runtime changes to accels have resulted in > some rather complicated code in Gtk and we'd be better off without this > feature. Additionally, the feature is disabled by default for quite > some time because enabling it results in lots of bug reports from > confused users. > > In the future we will likely gain some sort of action-database/factory > functionality (to replace the other half of GtkAction -- creating > proxies). I imagine accels will be registered with this database at > application initialisation time. > > I could see a hook (like a keyfile in ~/.config/ somewhere) that allows > advanced users to adjust their accels. An app restart would be required. > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=683738 > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
runtime accel changes
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. It's my personal opinion that runtime changes to accels have resulted in some rather complicated code in Gtk and we'd be better off without this feature. Additionally, the feature is disabled by default for quite some time because enabling it results in lots of bug reports from confused users. In the future we will likely gain some sort of action-database/factory functionality (to replace the other half of GtkAction -- creating proxies). I imagine accels will be registered with this database at application initialisation time. I could see a hook (like a keyfile in ~/.config/ somewhere) that allows advanced users to adjust their accels. An app restart would be required. [1] https://bugzilla.gnome.org/show_bug.cgi?id=683738 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
