KSelectAction

[Thomas Zander]

On Friday 28 July 2006 13:44, Hans Meine wrote:
> > GUIs are build more often without any accells assuming the manager
> > will add them. And thats a good thing.
>
> Actually, Hamish pointed out a killer argument against accelerator
> managers; when they were introduced, I was also among those who found
> the idea brilliant, however I changed my mind because *changing
> accelerators* are the worst thing to happen.

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. 
Its freaking impossible.

Having changing UIs in effect rarely adds top-level menus that will steal 
accels.  And those are the only ones that matter since accels inside a 
menu can be reused in each and every menu.

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.

Basically; you guys are asking for a step back due to the solution not 
being perfect.  That is, unless you know of a way to get accelerators in 
translations 100% perfect. Which, due to the translation process, is 
about as hard to solve as the middle east problem. :-)

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.
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060728/ca6ab3ac/attachment.sig>