News
Analyzed 1 day
ago based on code collected 1 day ago.
|
Posted
about 1 month
ago
Jos wrote a blog
post yesterday commenting on the complexity of the PIM problem. He raises an interesting concern about whether we would be all better if there was no Trojitá and I just improved KMail instead. As usual, the matter is ... [More] more complicated than it might seem on a first sight. Executive Summary: I tried working with KDEPIM. The KDEPIM IMAP stack required a total rewrite in order to be useful. At the time I started, Akonadi did not exist. The rewrite has been done, and Trojitá is the result. It is up to the Akonadi developers to use Trojitá's IMAP implementation if they are interested; it is modular enough. People might wonder why Trojitá exists at all. I started working on it because I wasn't happy with how the mail clients performed back in 2006. The supported features were severely limited, the speed was horrible. After studying the IMAP protocol, it became obvious that the reason for this slowness is the rather stupid way in which the contemporary clients treated the remote mail store. Yes, it's really a very dumb idea to load tens of thousands of messages when opening a mailbox for the first time. Nope, it does not make sense to block the GUI until you fetch that 15MB mail over a slow and capped cell phone connection. Yes, you can do better with IMAP, and the possibility has been there for years. The problem is that the clients were not using the IMAP protocol in an efficient manner. It is not easy to retrofit a decent IMAP support into an existing client. There could be numerous code paths which just assume that everything happens synchronously and block the GUI when the data are stuck on the wire for some reason. Doing this properly, fetching just the required data and doing all that in an asynchronous manner is not easy -- but it's doable nonetheless. It requires huge changes to the overall architecture of the legacy applications, however. Give Trojitá a try now and see how fast it is. I'm serious here -- Trojitá opens a mailbox with tens of thousands of messages in a fraction of second. Try to open a big e-mail with vacation pictures from your relatives over a slow link -- you will see the important textual part pop up immediately with the images being loaded in the background, not disturbing your work. Now try to do the same in your favorite e-mail client -- if it's as fast as Trojitá, congratulations. If not, perhaps you should switch. Right now, the IMAP support in Trojitá is way more advanced than what is shipped in Geary or KDE PIM -- and it is this solid foundation which leads to Trojitá's performance. What needs work now is polishing the GUI and making it play well with the rest of a users' system. I don't care whether this polishing means improving Trojitá's GUI iteratively or whether its IMAP support gets used as a library in, say, KMail -- both would be very succesfull outcomes. It would be terrific to somehow combine the nice, polished UI of the more established e-mail clients with the IMAP engine from Trojitá. There is a GSoC proposal for integrating Trojitá into KDE's Kontact -- but for it to succeed, people from other projects must get involved as well. I have put seven years of my time into making the IMAP support rock; I would not be able to achieve the same if I was improving KMail instead. I don't need a fast KMail, I need a great e-mail client. Trojitá works well enough for me. Oh, and there's also a currently running fundraiser for better address book integration in Trojitá. We are not asking for $ 100k, we are asking for $ 199. Let's see how many people are willing to put the money where their mouth is and actually do something to help the PIM on a free desktop. Patches and donations are both equally welcome. Actually, not really -- great patches are much more appreciated. Because Jos is right -- it takes a lot of work to produce great software, and things get better when there are more poeple working towards their common goal together. Update: it looks like my choice of kickstarter platform was rather poor, catincan apparently doesn't accept PayPal :(. There's the possiblity of direct donations over SourceForge/PayPal -- please keep in mind that these will be charged even if less donors pledge to the idea. [Less] |
||||||
|
Posted
4 months
ago
There's a lot of people who are very careful to never delete a single line from an e-mail they are replying to,
always quoting the complete history. There's also a lot of people who believe that it wastes time to eyeball such long, useless ... [More] texts. One of the fancy features introduced in this release of Trojitá, a fast Qt IMAP e-mail client, is automatic quote collapsing. I won't show you an example of an annoying mail for obvious reasons :), but this feature is useful even for e-mails which employ reasonable quoting strategy. It looks like this in the action: When you click on the ... symbols, the first level expands to reveal the following: When everything is expanded, the end results looks like this: This concept is extremely effective especially when communicating with a top-posting community. We had quite some internal discussion about how to implement this feature. For those not familiar with Trojitá's architecture, we use a properly restricted QtWebKit instance for e-mail rendering. The restrictions which are active include click-wrapped loading of remote content for privacy (so that a spammer cannot know whether you have read their message), no plugins, no HTML5 local storage, and also no JavaScript. With JavaScript, it would be easy to do nice, click-controlled interactive collapsing of nested citations. However, enabling JavaScript might have quite some security implications (or maybe "only" keeping your CPU busy and draining your battery by a malicious third party). We could have enabled JavaScript for plaintext contents only, but that would not be as elegant as the solution we chose in the end. Starting with Qt 4.8, WebKit ships with support for the :checked CSS3 pseudoclass. Using this feature, it's possible to change the style based on whether an HTML checkbox is checked or not . In theory, that's everything one might possibly need, but there's a small catch -- the usual way of showing/hiding contents based on a state of a checkbox hits a WebKit bug (quick summary: it's tough to have it working without the ~ adjacent-sibling selector unless you use it in one particular way). Long story short, I now know more about CSS3 than I thought I would ever want to know, and it works (unless you're on Qt5 already where it assert-fails and crashes the WebKit). Speaking of WebKit, the way we use it in Trojitá is a bit unusual. The QWebView class contains full support for scrolling, so it is not necessary to put it inside a QScrollArea. However, when working with e-mails, one has to account for messages containing multiple body parts which have to be shown separately (again, for both practical and security reasons). In addition, the e-mail header which is typically implemented as a custom QWidget for flexibility, is usually intended to combine with the message bodies into a single entity to be scrolled together. With WebKit, this is doable (after some size hints magic, and I really mean magic -- thanks to Thomas Lübking of the KWin fame for patches), but there's a catch -- internal methods like the findText which normally scroll the contents of the web page into the matching place no longer works when the whole web view is embedded into a QScrollArea. I've dived into the source code of WebKit and the interesting thing is that there is code for exactly this case, but it is only implemented in Apple's version of WebKit. The source code even says that Apple needed this for its own Mail.app -- an interesting coincidence, I guess. Compared with the last release, Trojitá has also gained support for "smart replying". It will now detect that a message comes from a mailing list and Ctrl+R will by default reply to list. Thomas has added support for saving drafts, so that you are not supposed to lose your work when you accidentally kill Trojitá anymore. There's also been the traditional round of bug fixes and compatibility improvements. It is entertaining to see that Trojitá is apparently triggering certain code paths in various IMAP server implementations, proprietary and free software alike, for the first time. The work on support for multiple IMAP accounts is getting closer to being ready for prime time. It isn't present in the current release, though -- the GUI integration in particular needs some polishing before it hits the masses. I'm happy to observe that Trojitá is getting features which are missing from other popular e-mail clients. I'm especially fond of my pet contribution, the quote collapsing. Does your favorite e-mail application offer a similar feature? In the coming weeks, I'd like to focus on getting the multiaccounts branch merged into master, adding better integration with the address book (Trojitá can already offer tab completion with data coming from Mutt's abook) and general GUI improvements. It would also be great to make it possible to let Trojitá act as a handler for the mailto: URLs so that it gets invoked when you click on an e-mail address in your favorite web browser, for example. And finally, to maybe lure a reader or two into trying Trojitá, here's a short quote from a happy user who came to our IRC channel a few days ago: 17:16 < Sir_Herrbatka> i had no idea that it's possible for mail client to be THAT fast One cannot help but be happy when reading this. Thanks! If you're on Linux, you can get the latest version of Trojitá from the OBS or the usual place. Cheers, Jan [Less] |
||||||
|
Posted
6 months
ago
I'm happy to announce that Trojitá, a
fast IMAP e-mail client, has become part of the KDE project. You can find it below extragear/pim/trojita. Why moving under the KDE umbrella? After reading the KDE's manifesto ... [More] , it became obvious that the KDE project's values align quite well with what we want to achieve in Trojitá. Becoming part of a bigger community is a logical next step -- it will surely make Trojitá more visible, and the KDE community will get a competing e-mail client for those who might not be happy with the more established offerings. Competition is good, people say. But I don't want to install KDE! You don't have to. Trojitá will remain usable without KDE; you won't need it for running Trojitá, nor for compiling the application. We don't use any KDE-specific classes, so we do not link to kdelibs at all. In future, I hope we will be able to offer an optional feature to integrate with KDE more closely, but there are no plans to make Trojitá require the KDE libraries. How is it going? Extremely well! Five new people have already contributed code to Trojitá, and the localization team behind KDE got a terrific job with providing translation into eleven languages (and I had endless hours of fun hacking together lconvert-based setup to make sure that Trojitá's Qt-based translations work well with KDE's gettext-based workflow -- oh boy was that fun!). Trojitá also takes part in the Google Code-in project; Mohammed Nafees has already added a feature for multiple sender identities. I also had a great chat with the KDE PIM maintainers about sharing of our code in future. What's next? A lot of work is still in front of us -- from boring housekeeping like moving to KDE's Bugzilla for issue tracking to adding exciting (and complicated!) new features like support for multiple accounts. But the important part is that Trojitá is live and progressing swiftly -- features are being added, bugs are getting fixed on a faily basis and other people besides me are actually using the application on a daaily basis. According to Ohloh's statistics, we have a well established, mature codebase maintained by a large development team with increasing year-over-year commits. Interested? If you are interested in helping out, check out the instructions and just start hacking! Cheers, Jan [Less] |
||||||
|
Posted
7 months
ago
I'm sitting on the first day of the Qt Developer Days in Berlin and am pretty
impressed about the event so far -- the organizers have done an excellent job and everything feels very, very smooth here. Congratulations for that; I have ... [More] a first-hand experience with organizing a workshop and can imagine the huge pile of work which these people have invested into making it rock. Well done I say. It's been some time since I blogged about Trojitá, a fast and lightweight IMAP e-mail client. A lot of work has found the way in since the last release; Trojitá now supports almost all of the useful IMAP extensions including QRESYNC and CONDSTORE for blazingly fast mailbox synchronization or the CONTEXT=SEARCH for live-updated search results to name just a few. There've also been roughly 666 tons of bugfixes, optimizations, new features and tweaks. Trojitá is finally showing evidence of getting ready for being usable as a regular e-mail client, and it's exciting to see that process after 6+ years of working on that in my spare time. People are taking part in the development process; there has been a series of commits from Thomas Lübking of the kwin fame dealing with tricky QWidget issues, for example -- and it's great to see many usability glitches getting addressed. The last nine months were rather hectic for me -- I got my Master's degree (the thesis was about Trojitá, of course), I started a new job (this time using Qt) and implemented quite some interesting stuff with Qt -- if you have always wondered how to integrate Ragel, a parser generator, with qmake, stay tuned for future posts. Anyway, in case you are interested in using an extremely fast e-mail client implemented in pure Qt, give Trojitá a try. If you'd like to chat about it, feel free to drop me a mail or just stop me anywhere. We're always looking for contributors, so if you hit some annoying behavior, please do chime in and start hacking. Cheers, Jan [Less] |
||||||
|
Posted
about 1 year
ago
It's my pleasure to announce that version v0.3 of Trojitá, a fast and
lightweight IMAP e-mail client based on the Qt library, is now available. For more details of what Trojitá is and who should use it, please see below. (Permanent ... [More] link to this announcement.) Changes since version v0.2.9.4 This release is a major one, bringing new features, plenty of bugfixes and two new contributors to the table. A quick summary of what has happened: Drastic reduction in memory usage Tagging e-mails (contributed by Shanti Bouchez) Faster fetching of data Much more efficient support for threading More robust IMAP support A new Debug menu Autocompletion of e-mail addresses (contributed by Thomas Gahr) Reporting server/client configuration through ID Support of multipart/related for full rfc2387 compliance Showing Trojita's homepage on start GUI fixes (now finally works in dark themes) SMTP works over SSL (contributed by Shanti Bouchez) Expanded unit test coverage Plenty of bugfixes and further improvements What is Trojitá Trojitá is a very fast and lightweight IMAP e-mail client written using the Qt library. What could make Trojitá interesting for you It's a pure Qt4 application with no additional dependencies; it builds in two-and-half minutes on a five-year-old laptop Robust IMAP core implemented using Qt's Model-View framework Standards compliance is a design goal On-demand message list and body part loading ("lazy loading") Offline IMAP support 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 Safe and robust dealing with HTML mail Please note that the "message sending" and "message composing" features of Trojitá are a bit lagging at this point and therefore it is not recommended to use Trojitá for these tasks apart from testing. Certain features of Trojitá depend on the IMAP server's functionality. Trojitá is written from the bottom-up as an IMAP client and is designed around its feature set. For example, threaded message viewing (ie. "conversations") is supported only if the server implements an appropriate extension for now. Trojitá is under heavy development, features are added on almost daily basis and the codebase is rapidly maturing. Certain useful features are still missing, there is no support for searching, for example. We have tickets opened for these, so please Cc yourself at the task tracker if you would like to follow the progress here. Finally, as with any software, Trojitá has some bugs which are already known and reported in the issue tracker and some which are still waiting for discovery. That said, it is safe to use to for *reading* mail. I've been doing that for several years on a production account, and I have never lost a mail with Trojitá. Please do not send e-mails with current version, though, as it is known to produce non-standard messages in certain circumstances. Where I can get it Our web has all the required information, but if you are impatient and just want to grab the tarball for v0.3, download from Sourceforge: http://sourceforge.net/projects/trojita/files/src/trojita-0.3.tar.bz2/download Trojitá is known to work on Linux, Mac OS X and Windows. It should also run on all platforms supported by Qt. A MeeGo version is still pending, though. Reporting bugs and wishes Please use the Redmine portal to report issues with Trojitá. If you do not want to be bothered by a registration, please at least send bug reports via e-mail or report them at the #trojita IRC channel on Freenode. Community Trojita could always use more people in the community. Areas in which people are needed most, as well as general guidelines about how we prefer to work are documented at the wiki. The IRC channel is #trojita on irc.freenode.net, the mailing list is trojita@lists.flaska.net (moderation required for non-subscribers, archived at various places etc). Acknowledgment A huge thank you goes to two new contributors who have submitted patches to make Trojitá better. It's my please to introduce Shanti Bouchez who is responsible for the new feature of tagging messages (and fixed STARTTLS for SMTP subscription in the process, among other things). The second contributor is Thomas Gahr who added e-mail auto-completion and fixed bugs. Since its inception in 2006, many other people have contributed to Trojitá as well. I'd like to mention patches from Benson Tsai, John Rogelstad, Andrew Brouwers, Gil Moskowitz, Jiří Helebrant, Jun Yang, Justin J, and Tomáš Kouba, who have all sent patches in. Finally, another huge thank you goes to anyone who has reported bugs or helped make Trojitá better in any way. Cheers, Jan [Less] |
||||||
|
Posted
almost 2 years
ago
I'd like to let you know that I've succeeded in building Trojitá for
MeeGo 1.2 Harmattan, as available on the Nokia N950. It is completely unusable for now due to the lack of a real mouse, but shows pretty nice that it *can* work :). A ... [More] screenshot: So, now that I know that the port actually builds and that the device can run my code, I'll plunge into the QML world and create a proper touch-friendly GUI. I'll keep you posted about my progress. I'd like to say a huge thank you to Nokia and its Developer Launchpad team, especially those that are responsible for the Community Device program. Nokia was kind enough to offer a loan of the N950 at no charge for the purposes of Trojitá development, and I really appreciate it. Cheers, Jan [Less] |
||||||
|
Posted
over 2 years
ago
I was thinking that it might be a good idea to share my view on how Trojitá is going on, and what my plans
for its future are. For a quick overview of Trojitá, a fast and lightweight IMAP client, please look at the project homepage ... [More] or see the FAQ. So, with version 0.2.9.3 out (what a nice number, isn't it?), it's time to take a look at what needs to be done before people can actually use Trojita on a daily basis. For my use case, the following is really lacking: The mail composer just sucks. It sucks in quite a few ways, from simple stuff like using proportional font (fixed yesterday) to mangling of all addresses which go through the widget or not saving the resulting message anywhere. It needs attention. Reply function, with proper quoting. Quick search through messages in the current mailbox. I often need to find a particular message, and simply typing a part of its subject, or a sender or recipient, is what I use most often. A full-blown multi-mailbox search is probably not needed at this point, but a basic, quick input box for searching would be very much welcome. There are many more issues, both major and minor, and I've filed some of them at the roadmap for Trojitá 0.3 in Redmine. It's very likely that I forgot to mention something, so please, feel free to submit issues and/or comment on what is the biggest blocker for you. I'm really looking forward to hearing from you, so if you have a minute and this post caught your interest, get Trojitá and write a mail to tell us what is lacking. All the best, Jan [Less] |
||||||
|
Posted
over 2 years
ago
It's my pleasure to announce that version v0.2.9 of Trojitá, a fast
and lightweight IMAP e-mail client based on the Qt library, is now available. For more details of what Trojitá is and who should use it, please see below. Most ... [More] of the changes in this version happened under the hood, but there is a bunch of user-facing improvements -- the most prominent one is probably the support for display of message threading (ie. "conversations"). (Permanent link to this announcement.) Changes since version v0.2 Refactored core IMAP code with safer command pipelining and increased robustness Message threading (aka "conversations") in the message list Plenty of bug fixes and GUI tweaks Improved unit test coverage Internal changes allowing making new UI frontends easier First real-world application of Trojitá in a library-like fashion Sadly, the Maemo version which first appeared as a beta during fall of 2010 could not be merged into the main repository before this release, but you should stay tuned for future updates. xTuple integration Trojitá is going to be featured as an addon for the xTuple business management software. Using Trojitá will enable xTuple customers to integrate e-mail messaging into their ERP systems. Please note that xTuple users should use packages provided by their vendor and not this source version. What is Trojitá Trojitá is a very fast and lightweight IMAP e-mail client written using the Qt library. While it is not intended for use as a regular e-mail client just yet, it could be interesting to play with it to see if the speed looks compelling to you. What could make Trojitá interesting for you: It's a pure Qt4 application with no additional dependencies; it builds in two-and-half minutes on a five-year-old laptop Robust IMAP core implemented using Qt's Model-View framework Standards compliance is a design goal On-demand message list and body part loading ("lazy loading") Offline IMAP support 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 Safe and robust dealing with HTML mail Please note that the "message sending" and "message composing" features of Trojitá are a bit lagging at this point and therefore it is not recommended to use Trojitá for these tasks apart from testing. Certain features of Trojitá depend on the IMAP server's functionality. Trojitá is written from the bottom-up as an IMAP client and is designed around its feature set. For example, threaded message viewing (ie. "conversations") is supported only if the server implements an appropriate extension for now. Many of the optional IMAP features are not utilized at this point; there is no support for searching, for example. We have tickets opened for these, so please Cc yourself at the task tracker if you would like to follow the progress here. Finally, as with any software, Trojitá has some bugs which are already known and reported in the issue tracker and some which are still waiting for discovery. That said, it should be safe to use to for *reading* mail. I've been doing that for several years on a production account, and I have never lost a mail with Trojitá. Please do not send e-mails with current version, though, as it is known to produce non-standard messages in certain circumstances. Where I can get it Our web has all the required information, but if you are impatient and just want to grab the tarball for v0.2.9, download from Sourceforge: http://sourceforge.net/projects/trojita/files/src/trojita-0.2.9.tar.bz2/download Trojitá is known to work on Linux, Mac OS X and Windows. It should also run on all platforms supported by Qt. Optimizations for mobile devices and the Maemo/MeeGo are in the works. Reporting bugs and wishes Please use the Redmine portal to report issues with Trojitá. If you do not want to be bothered by a registration, please at least send bug reports via e-mail or report them at the #trojita IRC channel on Freenode. Community Trojita could always use more people in the community. Areas in which people are needed most, as well as general guidelines about how we prefer to work are documented at Contributing to Trojitá. The IRC channel is #trojita on irc.freenode.net, the mailing list is trojita@lists.flaska.net (moderation required for non-subscribers, archived at various places etc). Acknowledgment I'd like to thank the KWest GmbH. and OpenMFG LLC, dba xTuple for their support in delivering the exciting new features of Trojitá. Another acknowledgment goes to the helpful folks at the #qt IRC channel and the qt-interest mailing list and also to everybody who reported an issue with Trojita or tested it against another IMAP server. All the best, Jan [Less] |
||||||
|
Posted
almost 3 years
ago
Today, on the 3rd day of the month, 333 days since the initial announcement, it's
my pleasure to announce the immediate availability of a new release of Trojitá, a Qt IMAP e-mail client. This is a technical preview release not designed ... [More] for production use, but rather a demonstration about what's been done in the past months. It should be safe to point it to your production IMAP server (it has never eaten any mail for me), but one shouldn't send real e-mails or otherwise rely on it apart from testing. New features in this release include: Much improved offline support with proper on-disk caching Tons of bugfixes (and I really mean it -- there have been plenty of them) Improved interoperability with various IMAP servers, including Microsoft Exchange Parallel connections to the IMAP server for increased performance when dealing with multiple mailboxes Improved connection handling, asynchronous operation and robustness, much more detailed error reporting IMAP protocol log Click-to-show external entities from HTML e-mail GUI tweaks The build system now uses QMake instead of CMake for better integration with Nokia's building infrastructure and embedded deployments Trojita now builds and runs on Windows and Maemo5 (Nokia N900 -- stay tuned for more news) Unit test coverage got expanded If you are interested, you can download Trojitá 0.2 now. There's also a GPG signature of the release. The same contents is available in the GIT repository under the v0.2 tag. I'd like to use this opportunity to thank KWest for their support which tremendously accelerated Trojitá's development. [Less] |
||||||
|
Posted
about 3 years
ago
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 ... [More] 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. [Less] |
||||||
Code Data
SCM Data
Community Data
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.