Some changes in KCmdLineArgs, KAboutData and KComponentData

Chusslove Illich caslav.ilic at gmx.net
Sun Jun 24 23:35:29 BST 2007


These classes are mostly taking naked const char* arguments, and returning
mix of the same, QByteArrays and QStrings, leading to chaos and pitfalls
when trying to handle non-Latin1 data. They are the only place in the API
where use of the I18N_NOOP macros, which are getting more evil by the day,
is required.

Therefore, I want to switch them as follows:

- all naked strings not eligible for localization, provided by the code
(e.g. in program prologues), are taken as QByteArray and expected to be UTF-
8 (i.e. the source files must be UTF-8),

- all strings which are to be localized are taken as KLocalizedString,
produced by ki18n* wrapper calls (instead of I18N_NOOP); KLocalizedString
delays translation to the point when it's required,

- all getter methods return properly decoded/translated QStrings, removing
the need for QString::fromXxx() and QFile::decodeName() calls, e.g. on the
arguments obtained from the command line.

The presence of KLocalizedString and QByteArrays in constructors also
clearly shows what is to be wrapped for translation, and provides compile-
time support for assuring that.

As a side convenience, I have added one more argument to all three classes'
constructors, to specify the translation catalog if not same as component
name. This allows to more naturally group smaller tools under same catalog,
and have versioned catalog names if required.

(I'm trying to swat as much flies as I can.)

Now the problem part :)

There is short of 1000 files in trunk/KDE alone which require changes due to
this (rewrapping I18N_NOOPs, shifting some constructor arguments around,
removing and adding QString/QByteArray conversions...)

I have been "training" a conversion script while converting kdelibs,
kdepimlibs and kdebase, and it seems to take care of most things. But it
cannot deal with some less usual QByteArray/QString conversion cases (mostly
when getting arguments from the command line), so one has to monitor the
build and fix these errors as they come by (mostly just adding
.toLocal8Bit() or changing QByteArray into QString, as more appropriate).

So my idea was to put the rest of trunk/KDE through the script, commit by
the noon tomorrow, and then we fix as it goes (kdelibs, kdepimlibs and
kdebase are done). Also to put up the script somewhere for outside of trunk/
KDE conversions (currently: http://caslav.gmxhome.de/misc/conv-kaboutdata.pl
)

---

In case you are wondering about the interface, other than switching data
types, the only very visible difference is in KCmdLineOptions. Before:

  static KCmdLineOptions options[] = {
      {"foo", I18N_NOOP("Description to foo"), 0},
      {"bar <arg>", I18N_NOOP("Description to bar"), "red"},
      KCmdLineLastOption
  };

  int main (int argc, char **argv)
  {
      ...
      KCmdLineArgs::addCmdLineOptions(options, "myopts");
      ...
  }

Now:

  int main (int argc, char **argv)
  {
      ...
      KCmdLineOptions options;
      options.add("foo", ki18n("Description to foo"));
      options.add("bar <arg>", ki18n("Description to bar"), "red");

      KCmdLineArgs::addCmdLineOptions(options, "myopts");
      ...
  }

-- 
Chusslove Illich (Часлав Илић)
-------------- 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/20070625/d7b99558/attachment.sig>


More information about the kde-core-devel mailing list