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


> 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]
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org

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