Re: GtkNotebook accelerators.

[Havoc Pennington <hp redhat com>]

Tim Janik <timj gtk org> writes: 
> 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).

Neither one of those things is necessary for the underline
accelerators, those issues are for the "Ctrl+S to save" type
accelerators. The underline accelerators make no sense to customize
and we don't allow customizing them now AFAIK. If we do we
shouldn't. For the notebook tabs you only care about the uline
accelerators.

If we just made the Alt+letter-in-label uline accelerators work
automatically for all visible widgets, that need not affect the
long-term revamp of the shortcuts such as Ctrl+S. The API is obvious
and already the same in every other toolkit.

I'm not sure which kind of accelerators the plug/socket changes
involve. Anyhow, point is that removing the need to consider accel
groups when doing uline accelerators would be fairly simple.

> 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. 

Yes we do do that for the uline accelerators. They do not change at
runtime, they are hardcoded in label names just as they are in other
toolkits.

We have one complicating factor which is the ability to remove/hide
widgets from containers, e.g. Qt lacks this. But not so hard to deal
with since Owen had to already handle this automatically for
plug/socket I think.

> we better refrain
> from making guesses what the finall outcome will be.

While I already agreed with you that we likely can't do it for 2.0, I
think three major industrial-strength toolkits doing something the
same way means that it's a pretty workable solution. So yes I think it
could be done pretty quickly.
 
> 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.

There's no need for considering MVC with the uline accelerators. By
definition, only the ones that are visible are supposed to work, and
the accelerators are tied to the displayed text, so it is a per-view
issue.

> i'm getting a feeling that you're
> not aware of all the issues involved. 

Stop with the condescension Tim, I was the one who proposed a MVC menu
API in the first place, over 2 years ago while working at EMC Capital
Management on Guppi. Not that it was a super-original idea, but
I've certainly thought about the issues as much or more than you have.
If you want to tell me about a specific issue please feel free, but so
far you are telling me nothing new.

> 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.
> 

And you snipped the part where I already said this was likely the
right thing to do. Again, I agree it is probably too much for 2.0.
But I do think it could make sense, depending on how things work out.

Havoc