KSelectAction

[Hans Meine]

On Friday, 28. July 2006 14:29, Thomas Zander wrote:
> As I stated earlier; if you build your GUIs with a minimum of hardcoded
> accels then suddenly things get a lot more consistent.
> This is due to translations practically being _unable_ to get this right.
I agree (although "more consistent" may be misleading, because it has nothing 
to do with the inconsistency problems we were talking about).

> The only problem you might have (and again, if you remove hardcoded
> accels) is if a submenu is suddenly enlarged due to a kpart or something.
> This is something that should be fixed. And can be fixed inside the accel
> manager.
That's one possible solution, but maybe not the best.

> Basically; you guys are asking for a step back due to the solution not
> being perfect.
Nah, we are not asking to "step back", that's ridiculous. ;-)  We are simply 
pointing out problems with the existing ac. manager.

But I still think that it may for example be desirable to specify not *fixed* 
accelerators (you already stated that this is problematic, and I agree), but 
*desirable* accelerators.  For example, with "Check for New Mail", one could 
associate the string "cnema" which contains the accelerators with decreasing 
priority.  If such a string is given, the manager could then try to assign 
the best possible accelerator (i.e. I find "e" much more memorizable than "i" 
for "Ch&eck ..." vs. "Check .... Ma&il").  Maybe that's overly complex (it 
would have to be translated, too...) and the existing manager already 
contains some basic AI logic (I did not check).

> Bottom line: I hope you can decouple the QMenu and QAction again like it
> was in KDE3. For example with the idea I posted earlier in this thread.
That's another thing which I 100% agree with.  The accel manager should *not* 
affect the action, but the widgets only (as it was before).  That's the only 
clean way AFAICS.

Ciao, /  /
     /--/
    /  / ANS