KDE Welcomes Trojitá, Offers Multiple E-Mail Clients


trojita

What is Trojitá?

Trojitá is a small, light, and fast IMAP e-mail client built with Qt.  Now, Trojitá is officially a part of the KDE project, and one of the first applications in the whole suite to support Qt5.  The announcement comes as a surprise to us, as there is already a well established e-mail client and PIM suite within KDE that takes advantage of KDE as a desktop environment.

So, why the move?  jkt has this to say:

After reading the KDE’s manifesto, it became obvious that the KDE project’s values align quite well with what wewant 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.

This move is increasingly interested after reading this paragraph from jkt’s blog.  He claims that Trojitá doesn’t require KDE to run, which we think is great!  There are a lot of apps in the KDE SC that are valuable as stand-alone applications, like Krita, but the KDE dependency list is a mile long for non-KDE users.  Trojitá eliminates that, but at the same time takes no advantage of KDE’s more prominent backend services, like Nepomuk.

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.

So what is the reason for welcoming this project into KDE?  It seems to be relatively bare-bones like Geary, where as Kontact is more of a be-all-end-all solution.  Is the KDE project admitting through welcoming Trojitá that Kontact will no longer be actively maintained?  Either way, we’re sure Trojitá is at least worth a look, and we wish them the best of luck.  In the meantime, if you want a stable, feature-rich, and rock-solid email client, why not just use Thunderbird?

Source | jkt’s blog

Via | Muktware

Dean Howell
Tags , , , ,

Dean Howell has over a decade of experience with Linux and nearly 2 decades of experience with computers in general. Currently, Dean is Editor-in-chief of The Powerbase and also works for one of the world's largest providers of Linux-based NVRs.

Related posts

  • Thomas Pfeiffer

    For people who only need an email client, Kontact and especially Akonadi may look like a pretty heavy system, and if they prefer Qt applications e.g. for consistency reasons, Trojitá may be right for them.
    And
    it is not uncommon for KDE to have several applications for the same
    purpose: See for example Amarok, JuK and Bangarang, or Konqueror and
    Rekonq, or Kate and KWrite, or Skrooge and KMyMoney, or… KDE embraces
    diversity and choice.
    Besides, though it sometimes looks like there
    is not much happening in Kontact right now (which isn’t really the case, btw.), it certainly won’t be left
    unmaintained since it’s the desktop / mobile client for the Kolab server, so actually several companies depend on it.

  • Shawn Rutledge

    My experience with KMail and Akonadi is that they spontaneously degenerate and stop working after a while, even with an ordinary corporate email account at work with mere thousands of messages in it. Restarting is not enough, the database gets corrupted. Not to mention that the memory leaks really add up if you stay logged in for a couple of months at a time, because when you exit kmail, akonadi stays resident. I went back to using Mutt, which I haven’t used for several years. So, I’m quite glad to see something which promises to be light and fast again. We’ll see if it actually is… so far no IMAP GUI app that I have tried has even stood a chance of handling my gmail account smoothly, because of its sheer size.

    • Jan Kundrát

      > Then, I clicked the INBOX folder, and it started chugging away, trying to download all the headers (more than half a million of them). After a quarter-hour or so it had filled up all 20 gigabytes of memory, plus all 4 gigs of swap, and of course the kernel killed it after that.

      Shawn, Trojita developer here. What you describe is not how Trojita works; there is nothing which triggers fetching of all message headers. In fact, Trojita will only fetch those which are visible to the user (and some preload in range of tens to hundreds of messages, but definitely not thousands and absolutely not all of them). Either you’ve hit a grave bug in there, or something really strange is going on.

      Could you please give it another try, this time with logging activated? (IMAP -> Debugging ->Log into /home/…) I’ll be very interested in the resulting log.

      As of the alleged 20GB RAM usage — again, I cannot imagine what could possibly consume so much memory. I regularly test Trojita on mailboxes with tens of thousands of messages and have not hit any problem.

      As of GMail, their IMAP implementation unfortunately leaves much to be desired. Trojita will work with it, mind you, but it won’t be as good as when talking to a modern IMAP server like Dovecot or Cyrus (the absence of ESEARCH, CONDSTORE, QRESYNC, CONTEXT=…, THREAD=… and other extensions really hurts). Trojita is an IMAP client, so it puts a certain amount of expectations on the IMAP server to behave reasonably. There are certain operations like showing messages in threads which won’t ever work well on GMail unless they implement the server-side support, so these are currently disabled on such servers.

      Anyway, please get in touch with me, either through jkt@flaska.net or via #trojita IRC channel on chat.freenode.net; the symptoms which you describe just do not match what I and other users have seen.

      With kind regards,
      Jan

      • Shawn Rutledge

        The out of memory condition indeed did not repeat the next time I ran it, even when I tried deleting imap.cache.sqlite first. And I can see that as I scroll through the messages, more headers are loaded. It’s basically usable and RSS is sitting at 482M right now (still a decent chunk of memory but oh well). I guess I can try deleting the settings too and starting over to see if the problem repeats.

        • Jan Kundrát

          Thanks for your response. I assume that this is on Linux, using Qt 4.8.x, and that you have something like 600k+ messages in your mailbox. Is that about right?

          Can we move this either to the project’s mailing list (trojita@lists.flaska.net, posts from non-subscribers are moderated) or to a private mail (jkt@flaska.net)? Discussing a mail client over a web forum feels just wrong and risks replies getting lost.

          Now there are a few issues I can see:

          1) I’ve so far tested up to 100k messages in a mailbox (and routinely use it on something between 50k and 60k). I have experimented with automated tests going way above that, but they didn’t use the GUI, just the underlying model. It sounds like an interesting idea to go up to a million, I’ll give it a try to see where the memory gets spent.

          2) Right now, Trojita keeps everything which was downloaded in the current session in memory until you reconnect. (If you have configured Trojita not to use the on-disk cache, the data are preserved in memory even across reconnects.) That’s something which can be improved. Have you downloaded big (tens of MB) message attachments, for example?

          3) The FETCH responses you see are required in IMAP in order to synchronize the mailbox state. If GMail supported CONDSTORE or QRESYNC extensions, they would happen just on the first synchronization, but in the current state, they will have to happen each time you open a mailbox. This is a GMail limitation.

          4) Do you recall the reason for why the connection was killed? Did Trojita show a particular error message, or was it a network timeout?

          5) The 3GB is also the RSS, not VSIZE, right? I’m asking because measuring VSIZE in an application which uses webkit is not meaningful.

          6) Trojita is an IMAP client which relies on the server to work efficiently. Features like searching the mailbox, showing messages in threads etc *need* the relevant features present on the server’s side. Sadly, GMail has its own business providing you with a non-standard interface to their service, so there is not a huge incentive for them to offer support for commands like THREAD or CONTEXT=SORT. The bigger mailbox you open, the worse the situation ends up like; opening a 600k “all messages” mailbox is something which *should* work (and fails to work reasonably well in your case), but I’m afraid you won’t be able to work with it efficiently with GMail; sorting in particular will be very, very painfull.

          Thanks for your report again, I’d like to find out what’s going on.

  • http://profiles.google.com/topchider1965 v m

    From the article:
    > So what is the reason for welcoming this project into KDE?

    From the article:
    > Now, Trojitá is officially a part of the KDE project, and one of the first applications
    >in the whole suite to support Qt5.

    Wouldnt that be reason enough considering the importance of Qt to the KDE projects?
    Makes sense to get all those who develop Qt based applications and libaries working together.

    Ive been using Thunderbird since whenever that was, so while I might not use Trojita,but dont think its ever a problem to have another approach. Besides, the name sounds like a tropical fruit drink. Or festive condoms.

    And does this really change much from the user point of view? It seems to me that if its not part of KDE Software Compilation nothing really changes from the user, packager and bug hunting perspective.

  • Pingback: Links 12/12/2012: Linux 3.7 is Out, OpenMandriva | Techrights

Top