--nextPart4187193.4yGDZx1fkR
Content-Type: text/plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

I've been away from my computer for a while working hard at my (non-IT) job=
=2E..

On Friday 28 July 2006 22:29, Thomas Zander wrote:
> 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.

I will try to make this happen (or ask TT to help).  I have some time comin=
g=20
up over the next few weeks (annual leave :).

I'll post again when I have some code (either on the accelerator manager si=
de=20
and/or on improved design tools).

Cheers,
Hamish.

--nextPart4187193.4yGDZx1fkR
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBE0F+EH8BtnSmIlUYRAsdxAJ94wEme7ZcxUXkZQ11aVoPx5FTxXQCgyjub
XoodDEl9MlPYzVogCG6d86k=
=l6b5
-----END PGP SIGNATURE-----

--nextPart4187193.4yGDZx1fkR--