Trojitá, an IMAP e-mail client, and KDE

I'm the maintainer of Trojitá [1], a fast and lightweight IMAP e-mail client written using Qt. I also have a KDE "SVN" account and am occasionally contributing to KPhotoAlbum (which is what get me hooked up with Qt and C++ in general). A few months ago, I started wondering about making Trojitá a part of KDE and after a couple of yesterday's conversaitons at the Qt Developer Days I've decided not to postpone this and ask right away.

Right now, Trojitá is a pure Qt application which does not use any KDE classes at all (it ships with an in-tree copy of basic, low-level stuff like the RFC2047 decoders, though). I would definitely like to retain the possibility to build without KDE installed at all, but I have nothing against optionally using KDE's stuff (and I've always wished to use KMessageWidget anyway).

I realize that this might be a slightly unusual case, but I've read through various HOWTOs, manifestos, public documents and wiki pages stating what KDE is, and it seems that there's nothing which would disqualify Trojitá form acceptance. However, in the end, it's always about what people think, how they feel and what they like. There's also an e-mail client in KDE already, and I'd hate to step on people's toes here. I also admit that (at least in the short term), Trojitá would probably gain much more than KDE if this proposal gets accepted. But I§m going to ask anyway.

So, would the KDE community be interested in making Trojitá a part of KDE's extragear?

With kind regards,

[1] <a href="" title=""></a>


Moving Trojitá to extragear

By =?UTF-8?B?SmFuI... at 11/21/2012 - 14:43

thanks for your encouragement. Trojitá, a fast IMAP e-mail client (homepage [1], more in-depth look [2], the KDE project page [3]) has spent the last week or so under playground and was just moved to kdereview (thanks to sysadmins for their excellent turnaround time). I'd appreciate people taking a look at the code [4]; I'm looking forward to your feedback. I'm hereby requesting a review for a move below the extragear/pim.

I've got a few questions or comments:

1) User's docs. Is it a hard requirement to have a documentation basically describing how the menus look like?

2) Krazy issues. I'm in the process of fixing many of them, but there are quite a few false positives. I've been told by the maintainers that some of them (like calling a QByteArray::startsWith(const char *)) are basically unfixable in the current Krazy. My opinion is that maintaining explicit excludes for these kinds of issues is not something which I would love to do. What's the consensus in KDE -- are these issues showstoppers?

3) Internationalization. The applciation uses QObject::tr(), not i18n() calls as it does not link to the KDE libraries. As I've outlined in my original e-mail, being able to build without KDE is something that I do not want to break. I've heard that there are options for making this work, I plan to investigate this in depth.

Looking forward to your comments and feedback.

With kind regards,

[1] <a href="" title=""></a>
[2] <a href="" title=""></a>
[3] <a href="" title=""></a>
[4] <a href="" title=""></a>

Re: Moving Trojitá to extragear

By =?UTF-8?B?SmFuI... at 12/06/2012 - 07:41

On Wednesday, 21 November 2012 19:43:13 CEST, Jan Kundrát wrote:
I believe that the only issue which was raised during the review was incompatible l10n. After applying several rolls of the duck type, the whole mess appears to work, more or less -- big thanks to Albert for being supportive, to Часлав and Yuri for their fixes, and sorry to the l10n teams for the endless stream of changes. For the record, the current setup is based on lconvert and a bunch of Python scripts (see [1] and [2]) which convert .pot produced by scripty's 4.6.3 version of lconvert into something which actually works.

It has been slightly over two weeks since I asked for the review, so unless there are any objections, I'll request the move below extragear/pim later today. If there are any comments or questions, I'll of course do my best to answer them.


[1] <a href=";a=blob&amp;" title=";a=blob&amp;">;a=blob&amp;</a>
[2] <a href=";a=blob&amp;" title=";a=blob&amp;">;a=blob&amp;</a>

Re: Moving Trojitá to extragear

By David Faure at 12/10/2012 - 05:50

On Thursday 06 December 2012 12:41:07 Jan Kundrát wrote:
I'm interested in more details about this, given that the tier1 frameworks in
KDE Frameworks 5 also use tr() and therefore will need something similar.

Do your scripts support MyObject::tr("foo"), with its implicit "context" of
"MyObject", which .po files don't support?

My current solution is QCoreApplication::translate("", "foo") so that an empty
context is used, but it's a bit ugly.

Re: Moving Trojitá to extragear

By Chusslove Illich at 12/10/2012 - 06:16

For the first time in KDE, Jan is actually doing exactly what should be done
with pure-Qt code. The system that all other pure-Qt pieces of code in KDE
repos use, was a hack from the start, and should be gradually moved away
_from. (Ki18n in KF5 will still provide it, not to annoy people, but with big
deprecation notes.)

The idea is that Scripty runs lupdate to create the TS file from the pure-Qt
code, then lconvert to convert it to POT, and deletes the TS and commits the
POT to the translation repository. When making a release, the maintainer
pulls in translated POs and includes them in the tarball (as extragear
packages normally do), and the build system runs lconvert to convert POs to
TS, and then compile and install them as usual for Qt-based translations. In
this way, everything rests on lupdate and lconvert doing their job properly.
For semantic differences between Qt and Gettext, it is upon lconvert to
define an unambiguous two-way mapping.

The scripts Jan had to write are a temporary fix, due to Scripty machine
having too old lconvert which produces broken POTs. Once lconvert is
updated, no third-party scripts should be necessary.

Re: Moving Trojitá to extragear

By David Faure at 12/13/2012 - 13:52

On Monday 10 December 2012 11:16:40 Chusslove Illich wrote:
Do you know how it handles contexts (usually class names)?

If it handles this correctly (so that tr() works at runtime), this is good
news then, it sounds like we can drop the weird QCoreApp::translate("",
"text") in KF5.

Re: Moving Trojitá to extragear

By =?UTF-8?B?SmFuI... at 12/13/2012 - 14:35

On Thursday, 13 December 2012 18:52:51 CEST, David Faure wrote:
I can confirm that lconvert from Qt 4.8.3 is enough to preserve the contexts (as long as translators retain the X-Qt-Contexts in the po header). If you're interested in a specific version, the relevant commit in Qt is probably a1c8fc04c17cfbf0060c81d442ffa2440a796112, QTBUG-10307.

If any of the following conditions are met in full:

1) the translators do not clobber up the file header and the lconvert used for both extracting the .pot file and building the application is up-to-date,
2) some trivial Python scripts are in place,

then it's enough to use the regular QObject::tr(). Trojita works like that.


Re: Moving Trojitá to extragear

By Chusslove Illich at 12/13/2012 - 16:50

I'm just wondering if we have slight misunderstanding here... The point is
that the running code uses straight Qt translation system, without anything
PO in sight. PO is only the medium to "talk" to translators. So by
definition everything depends only on sanity of lconvert (valid POT output,
lossless roundtrip conversion).

Re: Moving Trojitá to extragear

By David Faure at 12/18/2012 - 11:15

On Thursday 13 December 2012 21:50:29 Chusslove Illich wrote:
Yes, this seems clear to me, I don't see the misunderstanding.

My initial analysis, for KF5, was that the MyObj::tr() call at runtime
wouldn't be able to find the "MyObj" context in the translations, but Jan says
lconvert actually solves that by storing it in X-Qt-Contexts during the ts-
It just means that l10n will have to run lconvert during make install, in
order to install .qm files (compiled from .ts files), rather than .mo files, for
these frameworks which use tr() and not i18n().

Re: Moving Trojitá to extragear

By =?UTF-8?B?SmFuI... at 12/18/2012 - 12:00

On Tuesday, 18 December 2012 16:15:15 CEST, David Faure wrote:
In Trojita, the lconvert && lrelease is run at build time. Along with some path magic (which you might or might not want in your code, see [1]), this enables working l10n support even without having to run `make install` at first.

Do you guys think that this is reasonable?


[1] <a href=";a=blob&amp;h=a77327c629e6d2b532215376056829720b66b8e5&amp;hb=054cb1a3051614f7e09c35b3d700325ac16e4e54&amp;f=src%2FGui%2Fmain.cpp" title=";a=blob&amp;h=a77327c629e6d2b532215376056829720b66b8e5&amp;hb=054cb1a3051614f7e09c35b3d700325ac16e4e54&amp;f=src%2FGui%2Fmain.cpp">;a=blob&amp;h=a77327c629e6d2b532215376...</a>

Re: Moving Trojitá to extragear

By =?UTF-8?B?SmFuI... at 12/10/2012 - 07:17

On Monday, 10 December 2012 11:16:40 CEST, Chusslove Illich wrote:
Chusslove's description is correct, there was just one more tweak required -- one of the translators produced a .po file where some lines were starting with "#~| " and lconvert was refusing to work with that, considering such sequences an error -- see line 4427 of [1]. I'm not familiar with the gettext specs so I don't know if the bug is in lconvert or in whatever tool which produced the output. (I read the spec and could not decide.)

If you guys know what a tool shall do upon seeing lines like that, I can send a patch for lconvert to do the right thing.

Apart from that, I also explicitly add "X-Qt-Contexts: true\n" to the translation of "" at the top of the file -- not sure why translators are dropping it and it is required for contexts to work properly.


[1] <a href=";view=markup" title=";view=markup"></a>

Re: Moving Trojitá to extragear

By Chusslove Illich at 12/10/2012 - 07:56

#~| is a normal construct for PO files, so lconvert should be modified to
accept it (i.e. ignore it, as it should ignore all #~ lines).

This is maybe a bug in the translation editing tool that translators use.
Header fields ("" message is called the header) should not be touched
without purpose. Nothing to change in lconvert here.

Re: Moving Trojitá to extragear

By =?UTF-8?B?SmFuI... at 12/07/2012 - 05:41

Trojita now lives under extragear/pim.

With kind regards,

Re: Moving Trojitá to extragear

By Yuri Chornoivan at 11/21/2012 - 16:07

написане Wed, 21 Nov 2012 20:43:13 +0200, Jan Kundrát < ... at flaska dot net>:

No. But it's a good practice [0]. Nobody needs to know how the menu looks
like (if you do not mind about accessibility) but it is good to know if
there are non-obvious features or some advices about workflow and
configuration. ;)

As you do not have i18n (why it can be like in other pure-Qt and
Gettext-based applications like LyX or Marble?), it is of no sense to have
DocBook docs, but you can consider to put something (at least a link on
[1]) on UserBase [2].

Just my 2 cents.

Best regards,

[1] <a href="" title=""></a>
[2] <a href="" title=""></a>

Re: Moving Trojitá to extragear

By Albert Astals Cid at 11/21/2012 - 15:53

El Dimecres, 21 de novembre de 2012, a les 19:43:13, Jan Kundrát va escriure:
No, at the moment our workflow does not support translations of applications
that don't use kdecore.

I.e. if you don't use "i18n()" or "tr() + kdecore (and actually this one has a
missing feature because someone in Qt decided to make a method not virtual)"
you can't get our .po/.mo system work-flow to work.

Not having translations seems a big issue to me.


Re: Moving Trojitá to extragear

By =?UTF-8?B?SmFuI... at 11/22/2012 - 07:02

On Wednesday, 21 November 2012 20:53:14 CEST, Albert Astals Cid wrote:
Agreed; my goal never was "screw transaltions", but "let's make it possible to build without kdelibs". I don't care whether the source code uses calls to tr() or i18n() or some other wrapper.

I'm taking a look at how Marble works, it looks like their workflow indeed uses po2ts. I haven't found out how they make the .po files out of the tr() calls yet.

With kind regards,

Re: Moving Trojitá to extragear

By =?UTF-8?B?SmFuI... at 11/22/2012 - 18:31

It took quite a few hours, but it looks like I've tamed the beast.

I wanted to follow the way how Marble works, i.e. calling QObject::tr and converting between the .ts and .po files. This turned out to be a problem because QObject::tr expects the context to be a name of the class while the xgettext, as used by, works with file names. I have no idea how come that Marble's tr() calls work -- when I used the same, nothing would get translated.

The setup is documented at [1]. I've checked that the setup works locally (through running the script from kde-l10n-kde4's scripts); the message extraction depends on having access to `lupdate` and `ts2po`. How can I verify that the .po files for translators are generated?

To test by hand, follow these steps:

1) Set up the kde-l10n-kde4 repo [2]
2) Run `` from that repo while in Trojita's top-level directory. A new file called po/trojita_common.pot shall appear.
3) Either produce po/trojita_common_$LANG.po in your favorite tool, or get a sample translation [3]. Put it into the po/ directory.
4) Run qmake again. This is required because the globs are evaluated at qmake time, not at build time, AFAIK (pointers to how to "fix" that welcome).
5) Run `LC_ALL=cs_CZ.utf-8 ./src/Gui/trojita` and notice that the "View" menu is called "Zobrazit".
6) It works!

I believe that the localization has been taken care of by these changes (provided that the setup actually works and KDE's infrastructure/Scripty/whatever is OK with the scripts in my project). Albert, could you please confirm that this addresses the point you've raised?

(As an aside, it looks like my messages to this list go to the moderators' queue. That was surprising, but I assume it's by design. Are the reasons for that documented somewhere?)


[1] <a href=";a=blob&amp;h=fadae711042660641391c2fccd6c7fa871d75de9&amp;hb=5f7b9ada6306568d3c8652e3c5edb2700fdd91ed&amp;f=po%2FREADME" title=";a=blob&amp;h=fadae711042660641391c2fccd6c7fa871d75de9&amp;hb=5f7b9ada6306568d3c8652e3c5edb2700fdd91ed&amp;f=po%2FREADME">;a=blob&amp;h=fadae711042660641391c2fc...</a>
[2] <a href="" title=""></a>
[3] <a href="" title=""></a>

Re: Moving Trojitá to extragear

By =?utf-8?q?Burkh... at 12/04/2012 - 08:03

Am Donnerstag, 22. November 2012, 23:31:43 schrieb Jan Kundrát:
Using a simple

$XGETTEXT_QT `find src/ -name \*.cpp` -o $podir/trojita_common.pot

will avoid the duplicated messages make Scripty happy.

Re: Moving Trojitá to extragear

By =?UTF-8?B?SmFuI... at 12/05/2012 - 10:25

On Tuesday, 4 December 2012 13:03:57 CEST, Burkhard Lück wrote:
Hi Burkhard,
the latest log [1] looks fine to me. Could you please confirm that it is indeed OK now?

With kind regards,

[1] <a href="" title=""></a>

Re: Moving Trojitá to extragear

By =?utf-8?q?Burkh... at 12/06/2012 - 08:55

Am Mittwoch, 5. Dezember 2012, 15:25:21 schrieb Jan Kundrát:

Re: Moving Trojitá to extragear

By Albert Astals Cid at 12/04/2012 - 08:07

--- El mar, 4/12/12, Burkhard Lück <> escribió:

But that won't work code-wise since he's not linking to kdecore.


Re: Moving Trojitá to extragear

By =?UTF-8?B?SmFuI... at 12/04/2012 - 09:09

On Tuesday, 4 December 2012 13:03:57 CEST, Burkhard Lück wrote:
Hi Burkhard,
I'm sorry for the trouble. Unfortunately, the output that xgettext produces when scanning the tr()-using sources does not work out of the box with the Qt's translation system (and ts2po/po2ts is not enough, see the git history for details) -- so it appears that lconvert's is what we're stuck with.

It looks like the trojita_common.pot which is in SVN is different than what I get locally (Gentoo, Qt/4.8.3) -- notably, they differ in "msgctxt" and "#. ts-context" prefixes. Could you please have a look at what happens when you run scripty over [1]? Or alternatively, how can I run the script which produces the error log myself?

If the "new" format works, I'll be happy to sed the output so that it matches the "new" style even on older lconvert.

With kind regards,

[1] <a href="" title=""></a>

Re: Moving Trojitá to extragear

By Chusslove Illich at 12/04/2012 - 09:32

Other than the difference in contexts, the POT file is actually invalid (due
to duplication of messages, which must be unique by msgctxt+msgid). I think
the only reasonable solution is to put a newer lconvert onto the machine
where extraction happens.

Re: Moving Trojitá to extragear

By =?UTF-8?B?SmFuI... at 12/04/2012 - 15:44

On Tuesday, 4 December 2012 14:32:20 CEST, Chusslove Illich wrote:
My gettext skills are very sub-par, I know just what I've read in the last two weeks. It looks like there are the following differences between what's in the SVN and what my copy of lconvert generates:

1) "msgctxt" is replaced by the "#. ts-context" construct (and is on a "wrong" place)
2) "#, fuzzy" gets added
3) "#, qt-format" strings are removed
4) file names are different and are printed strictly on a one-per-line basis
5) QML files are not processed

I have added a Python script to the conversion process which fixes the first two issues. I hope that 3) and 4) are harmless. Point 5) sucks, but I can do without that funcitonality for now.

I don't have any say in this, and I assume that folks in charge of that machine have better things than upgrading so that Trojita's special setup can work well -- and I fully agree with their evaluation; I'm the one being different, so I have to keep the pieces.

I can easily run the extraction on my own, using lconvert which is recent enough. Would you guys get very upset if the changed to just call wget http://... ?


Re: Moving Trojitá to extragear

By Albert Astals Cid at 12/08/2012 - 08:56

El Dimarts, 4 de desembre de 2012, a les 20:44:06, Jan Kundrát va escriure:
Just for completion (since this has been resolved already), yes, i'd very
upset if you put a wget there.


Re: Moving Trojitá to extragear

By Albert Astals Cid at 11/22/2012 - 15:32

El Dijous, 22 de novembre de 2012, a les 12:02:17, Jan Kundrát va escriure:


Re: Moving Trojitá to extragear

By Michael Pyne at 11/22/2012 - 11:58

On Thursday, November 22, 2012 12:02:17 Jan Kundrát wrote:
If you're willing to support translations only in the event that kdelibs is
available then you can use i18n all the time, and use a macro to define it as
a no-effect wrapper when kdelibs isn't available.

With other (non-KDE) translations systems it might also be possible to flag
i18n() as the "translatable string" marker with a bit of extra work to make
i18n() integrate with the alternative translation system.

- Michael Pyne

Re: Moving Trojitá to extragear

By Martin Sandsmark at 11/22/2012 - 07:18

On Wed, Nov 21, 2012 at 08:53:14PM +0100, Albert Astals Cid wrote:
Has this been fixed in Qt5?

Re: Moving Trojitá to extragear

By Albert Astals Cid at 11/22/2012 - 15:32

El Dijous, 22 de novembre de 2012, a les 12:18:51, Martin Sandsmark va


Re: Moving Trojitá to extragear

By =?utf-8?Q?Thoma... at 11/21/2012 - 16:52


Re: Moving Trojitá to extragear

By Albert Astals Cid at 11/21/2012 - 18:10

El Dimecres, 21 de novembre de 2012, a les 21:52:43, Thomas Lübking va
po2ts might be actually a better solution than using sed

It might work yes, but to be honest I have a workload big enough for now that
supporting people that doesn't want to use kdecore.

On the other hand we will have to support something like this since the
frameworks effort has decided their first tier needs translations and can't
use i18n() so if anyone was to work on this it'd be useful for KF5 too.


Re: Trojitá, an IMAP e-mail client, and KDE

By Christoph Feck at 11/14/2012 - 09:21

On Tuesday 13 November 2012 16:38:35 Jan Kundrát wrote:
To request a git repository in playground, please use
<a href="" title=""></a>

You could then also request an entry in the bug tracker, so that bugs
can be easily reassigned to KDE components, in case they are "not your

PS: Be prepared to handle 1000+ votes on "Add POP3 support" request ;)

Christoph Feck (kdepepo)
KDE Quality Team

Re: Trojitá, an IMAP e-mail client, and KDE

By Ivan Cukic at 11/14/2012 - 08:09


I don't think it would be the first - iirc, some KDE apps already have a Qt-
only build mode (Marble if I'm not mistaken)

The proper procedure for this would be - place it into the playground, when
you think it is ready, post it to the review.

We already have situations where we have more than one application for a
single purpose, so I don't think people will mind having another one, as long
as it is in extragear, and not a part of KDE SC.