Re: GtkNotebook accelerators.

[Tim Janik <timj gtk org>]

On 1 Mar 2001, Havoc Pennington wrote:

> Tim Janik <timj gtk org> writes: 

> > also that doesn't account for accelerator change negotiation, i.e.
> > when accelerators are being loaded from a config file or changed
> > on menu items.
> 
> Well yes, that has to be considered. But the basic deal is that on all
> other toolkits (Swing, Qt, WinForms), you simply set the accelerator
> on a widget, and set up a connection between the displaying label and
> the accelerator, and things Just Work. i.e. accelerators are
> automatically installed when the widget is visible, and there's no
> need to manually manage accel groups. This is the behavior we should
> also have.

things aren't that simple if you allow runtime changes of accelerators as we
do (and loading accels from config files falls into this category as well).
if you take the simple standpoint that at application creation the accel
settings are fixed, you can make the simplification to not worry about
accel groups, but we don't do that for gtk and thus we can't simply copy
another toolkits behaviour in that regard. that being said, the current
handling with explicit exposal of accel groups is a bit complex and needs
to be changed but we can't di that on a 2.0 timescale.
think e.g. multiple document windows of a doc-editing application, say you
change the binding of File/Open, that has to be propagated to the other doc
windows as well, and since we don't have a Model/View separation for menu
items yet we use accel groups to patch around lack to get the propagation
anyways.
long term, we need to sit down and redesign menus (or more generally
"choices/actions") and accelerators from scratch with all the requirements and
current problems in mind. untill that's been done, we better refrain
from making guesses what the finall outcome will be.

> > we can't sufficiently resolve this for 2.0, there's simply too
> > little time left for a complete revamp of the way accelerators
> > work, and that's what we need long term.
> > so this issue definitely will be punted to post-2.0, untill then,
> > people can use different accel groups for notebook pages (we migth
> > want to introduce convenience functions to a) block whole accel
> > groups, and b) couple an accel groups blocked state to notebook
> > page visibility, but that's about it).
> 
> Well, there's still the issue of plug/socket which also requires accel
> changes; at that point a revamp may be almost as easy as hacking
> around things in plug/socket and notebook. The thoughts we had on how
> to revamp things don't make it a huge project, since it should be kept
> pretty simple, and we'd keep accel group around as implementation
> detail and/or power-user feature, but it would still take a week or so
> to finish up presumably.

i highly doubt that a couple of plug/socket and notebook workarounds amount
to the same efford that an MVC based choice/accel system involves that we'd
want to have and maintain long term. i'm getting a feeling that you're
not aware of all the issues involved. so lets see that we fix the urgent
things for 2.0 and after that have a planning session to revamp the whole
system to something that fits all requirements.

> 
> Havoc
> 

---
ciaoTJ