Re: [Bug 90509] Account types can not be translated in account dialog

On Tuesday 17 July 2007 20:58, Thomas McGuire wrote:
> ------- Additional Comments From Thomas.McGuire gmx net  2007-07-17
> 20:58 ------- SVN commit 689148 by tmcguire:
>
> Update the way the type of the account is stored.
> Now, we use enums instead of strings.
> Add the names of the types to KAccount. They can now be translated.
> Also, provide an update script for easy config migration.

Storing enums as int values is evil because the next guy will add an 
enum value in the middle instead of appending it or some other guy will 
sort the enums alpha-numerical. So far the worst incident caused by 
enums stored as int values was POP filters deleting messages from the 
POP server instead of downloading them (because somebody had re-ordered 
the enum values).

The lesson to learn: Never ever store enum values as int values. Always 
store them as strings.

The good thing is that Qt provides very nice means for this as Simon 
showed us in Glasgow. Simon, where can we find the slides of your talk 
and the sources of your examples?

Anyway, for a non-QObject-derived class like KAccount one adds Q_GADGET 
to the class (just as one adds Q_OBJECT to a QObject-derivative; 
Q_GADGET is currently not document, but Simon promised that it will be 
in Qt 4.4). This macro will add the necessary magic for making the 
Q_ENUMS macro usable with KAccount. In fact, it adds 
  static const QMetaObject staticMetaObject
to the class. The static meta object can then be used for getting to the 
QMetaEnum (via QMetaObject::enumerator() ?). And QMetaEnum provides 
keyToValue() and valueToKey() which we need for writing/reading the 
enum values to/from the config file. I have forgotten the exact 
details.

Of course, this does not cover the translation of the display names 
corresponding to the enum values. For this something like 
KAccount::typeName() will still be needed. FWIW, I would put the code 
from typeName() into a static method displayNameForType( 
KAccount::Type ) so that it can also be called without an actual 
instance of KAccount, e.g. for filling a combobox (or whatever) with 
the display names of available account types as for example in 
KMAcctSelDlg.


Regards,
Ingo

_______________________________________________
KMail developers mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kmail-devel

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

iD8DBQBGnSabGnR+RTDgudgRAgfeAJ42mGbxzVydzLZ78dxtRAXNLyTkUACdEgRZ
KFJTGeqiKvo8gK8L+SAi3Yg=
=a41c
-----END PGP SIGNATURE-----