jkt's blog

History

When I looked at the state of graphical IMAP e-mail clients several years ago, I was not really impressed. KMail from then-current KDE3 did not do a proper job for me (numerous IMAP bugs like its inability to work as about every other IMAP client when deleting messages, bug 26986 -- there were more issues than that, but years have left my memories washed out a bit), Thunderbird would crash for me every once a week, at least, and I just happened to like KDE applications more than Gnome stuff, so I did not spend much time looking at Evolution. Many MUAs looked like a classic generic e-mail clients designed with POP3 in mind with IMAP added late in the development cycle, while others supported wide range of IMAP features, yet lacked in the GUI part of the problem. In short, using none of these applications made me feel happy.

A programmer not feeling happy is a receipt for disaster. I was about to finish my high school, so I had plenty of time at hand. I was experimenting with Python, so that seemed like a natural implementation language, too. In the end, I started a project called trojita whose remnants could still be seen in an abandoned SVN repo.

Coding in Python was fun. I tried several different approaches to the design of my pet program, I was playing with technologies I had no experience with, I even showed my "IMAP library" at my final exam as an example of a project I made. It did not have much functionality, in fact, only the IMAP parser had been completed, but it was an educative experience nonetheless and I passed the exam.

After some time, however, I discovered Qt and C++ and felt in love. I joyfully returned to the realm of statically-typed languages and suddenly felt a lot better. I began porting my Python library to Qt/C++. It was not really a port, rather a first complete rewrite of my project. Anyway, it did not take long and the C++ version suddenly offered more functions than the old Python branch, with unit tests as a nice added bonus.

Qt's Interview architecture, the Model/View classes, seemed like a decent implementation of the MVC patter I was poking around to use. Several months have passed, and suddenly trojita was able to show a tree of mailboxes stored on a remote IMAP server, listing messages contained therein and showing message bodies. I choose to finish the program as a part of my bachelor's thesis, and ultimately, I succeeded.

The Code

So, in a few blogposts starting with this one I'm going to introduce a new Qt IMAP e-mail client to the world. I hope I will get some attention and folks looking at the code and trying to run the application. I'd love to get some feedback on program design, code quality and general usability as well.

The code is hosted at Gitorious, and a bachelor thesis about Trojitá (PDF) (mirror) which explains its design and compares it against several alternatives is available, too. Perhaps the most interesting part is Chapter 3 which describes the architecture of the application, and Chapter 4 in which I compare Trojitá to several other MUAs on the market. All information about Trojitá are also aggregated on Trojitá's homepage (any web designer listening? :) ). Here is the obligatory screenshot:

Trojitá's Features

Some highlights of Trojitá are:

• A pure Qt4 application with no additional dependencies
• Robust IMAP core implemented using Qt's Model-View framework
• Standards compliance is a design goal
• Support for bandwidth-saving mode aimed at mobile users with expensive connection
• IMAP over SSH -- instead of going over an SSL socket, the server could be accessed via SSH
• On-demand body part loading
• Offline IMAP support (you can access data you already have; there's no complete "offline mail access" yet, though)
• Safe dealing with HTML mail (actually more robust than Thunderbird's)

The thesis was completed several months ago. Since that time, I've removed the dependency on std::tr1::shared_ptr and switched to Qt's QSharedPointer which in turn requires Qt-4.5 or newer. There wasn't much more changes since then, as I enjoyed quite a long vacation, but I guess I can tell the development is getting faster again.

How to Use it

It's a fairly standard CMake setup:

git clone git://gitorious.org/trojita/trojita.git
cd trojita
mkdir _build
cd _build
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
make -j4
./trojita

Please do join the #trojita channel on Freenode and tell me how you like this application. I'm open to any suggestions and would love to hear any feedback, too.

---

As you can see, this blog is a static HTML page, so you can't post any comments here. However, I'm eager to answer any questions sent to my mail, both via e-mail and in subsequent blog posts.

This weekend I had the pleasure of travelling to a beautiful city of Schlitz. After some six hours on train, I arrived to KWest GmbH, a cool company which specializes in manufacturing of embedded systems, and which is nowadays busy developing an Internet tablet for a German ISP. It turned out that the company likes Qt and free software and is not particularly happy with the availability of Qt-based IMAP clients. As it happens, I was not happy with the world of IMAP clients, either, and I chose that as a subject for my bachelor's thesis a few years ago.

After having met KWest's representatives, we came to conclusion that Trojita is indeed a suitable IMAP e-mail client for them, and that while they do have a skilled development team, it would be beneficial for both me and them to work together. We have agreed that they will focus on bringing the GUI of the application up to speed with modern standards, adding important features like address book and a decent platform integration to the mix, while I will focus on what I'm good at, that is, improving the IMAP support, especially the offline mode.

The good thing for the community is that Trojita will remain under the GPL and that I'll be able to spend much more time on its development. Given enough time, Trojita will mature, and if everything works well, we will see a nice Qt e-mail application pretty soon. As usually, both the bug tracker and all source code remains freely available without any restrictions.

I'd like to thank KWest GmbH for giving me an opportunity to work on a free software project that I'm interested in, especially to Sebastian for inviting me and to Markus for being a nice guy to work with. And if you have some spare time and are looking for a nice little city to visit, be sure to stop in Fulda and Schlitz, their city centers look as if they came straight from a fairytale.

I've spent more than 10 hours in total changing the build system of Trojitá from CMake to QMake upon a request from KWest. The process was very painful for me, so I think it's worthwhile to include some comments about what were the major obstacles.

The first step, "getting the beast to build", was actually pretty easy -- I (KWest actually) simply created a list of all files in the tree, added them into a single .pro file, removed the #includes for MOC, commented out the unit tests and rebuilt the project. That was the easy part; qmake simply built bunch of .o files and linked them together.

Problem with unit tests is that they all define the main() function. Therefore, as far as I know, one has to create a separate .pro file for each unit test, use the template = subdirs and put each test into a subdirectory. That's slightly annoying when compared to CTest (see the Trojita's git repository for how the CMakeLists.txt looked before we switched), but doable and actually pretty straightforward. Now, a much bigger problem is persuading QMake to create static libraries and using them properly and in a cross-platform way. I care about the Unix platform, some users want to play with Trojita on Windows, and there's that secret device KWest is building.

Trojita currently consists of several parts; we have the core IMAP stuff (which itself consists of three or four components), the GUI layer, some third-party modules even (like Witold Wysota's qwwsmtpclient, the Qt's iconloader, a unifying layer for QProcess and QSslSocket etc). The unit tests for the IMAP protocol clearly should not care about icons at all and shall ignore GUI classes, too, but they do need to link against the IMAP protocol implementation. A reasonable way to express that in the build system is to create a static library for the IMAP stuff and link it to the rest of the GUI when building the application and to each of the unit tests when building tests. That's where problems with QMake start to hurt.

Unlike CMake, under which the static libraries are extremely easy to write, QMake's support and documentation for static libraries leaves much to be desired. A reasonable request is, for example, expecting the build system to isolate me from stuff like library placement -- I just want to tell it that I need to link against bunch of .arelease and debug when caring about Windows builds.

Another expectation is that QMake should relink each binary if any static library it depends on gets rebuilt. Too bad, using QMake, you have to include the library name in three places for this to happen: at first, you have to use LIBS += -Lpath/to/your/lib/directory, then you got to actually link to it by LIBS += -lnameOfTheLibrary, and finally you have to take care of the rebuilding by PRE_TARGETDEPS += full/path/and/the/libIdentifier.a. Oh, and please do not forget about CONFIG += ordered, or the PRE_TARGETDEPS won't affect much stuff anyway. Yuck!

There's the CONFIG += create_prl and CONFIG += link_prl, but they did not help me. I guess they are used for specifying dynamic libraries on which the currently processed static library depends. They certainly did not fix my problems when I played with them, though.

Anyway, this is what I ended up with:

---

Project file for the GUI stuff, src/Gui/Gui.pro:

(...)

trojita_libs = Imap/Model Imap/Parser Imap/Network MSA Streams iconloader qwwsmtpclient

myprefix = ../
include(../linking.pri)

---

Each of tests/test_*.pro:

TARGET = test_Imap_LowLevelParser
include(../tests.pri)

---

A helper file for unit tests, tests/tests.pri:

QT += core network
CONFIG += qtestlib no_lflags_merge
DEFINES -= QT3_SUPPORT
DEPENDPATH += ../../src/
INCLUDEPATH += ../../src/ ../
TEMPLATE = app
HEADERS += ../qtest_kde.h


trojita_libs = Imap/Parser Imap/Model Imap/Parser Streams
myprefix = ../../src/
include(../src/linking.pri)

SOURCES += $$join(TARGET,,,.cpp)
HEADERS += $$join(TARGET,,,.h)

---

And finally, the file, src/linking.pri:

for(what, trojita_libs) {
    mylib = $$replace(what,/,)
    unix {
        mypath = $$join(what,,$${myprefix},)
    }
    win32 {
        CONFIG( debug, debug|release ) {
            mypath = $$join(what,,$${myprefix},/debug)
        } else {
            mypath = $$join(what,,$${myprefix},/release)
        }
    }
    LIBS += $$join(mypath,,-L,)
    LIBS += $$join(mylib,,-l,)
    PRE_TARGETDEPS += $$join(mypath,,,$$join(mylib,,/lib,.a))
}

---

Compare the above to the elegance of CMake, depicted below out of sentiment:

set(libImap_SRCS
    ${CMAKE_CURRENT_SOURCE_DIR}/Imap/Parser/Parser.cpp
    ${CMAKE_CURRENT_SOURCE_DIR}/Imap/Parser/Command.cpp
...
)
...
add_library(Imap ${libImap_SRCS})
...
target_link_libraries(Imap Streams ${QT_QTGUI_LIBRARY} ${QT_QTCORE_LIBRARY})
...
target_link_libraries(trojita Imap MessageView ModelTest MSA QwwSmtpClient QtIconLoader)

That's what I call ease of use. Anyway, the QMake change just had to be done (when the customer asked if I could migrate to QMake, I said I had no preference) and it's been done now. This blog post is just a rant, and hopefully might eventually make its way to Google's results for "qmake static library".

There's always the possibility that I'm just too dumb to miss a completely obvious way to work with static libraries in QMake. If that's indeed the case, I sincerely apologise to QMake designers. Also, I offer one beer as a sign of appreciation to the first person who shows me that I'm indeed missing something from the big picture. In the meanwhile, have fun -- QMake has a lot of nice features and I'm no longer afraid to use it, now that the static libraries are used properly. The make test is still missing, but I guess I can live without that for a while.