I’ll stick with Thunderbird still

Even though it hasn’t been an year yet that I moved to KDE, after spending a long time with GNOME 2, XFCE and then Cinnamon, over the past month or so I looked at how much of non-KDE software I could ditch this time around.

The first software I ditched was Pidgin — while the default use of GnuTLS caused some trouble KTP works quite decently. Okay some features are not fully implemented, but the basic chat works, and that’s enough for me — it’s not like I used much more than that on Pidgin either.

Unfortunately, when yesterday I decided to check whether it was possible to ditch Thunderbird for KMail, things didn’t turn out as nice. Yes, the client improved a truckload since what we had at KDE 3 time — but no, it didn’t improve enough for make it usable for me.

The obvious problem zeroth is the dependencies: to install KMail you need to build (but don’t need to enable) the “semantic desktop” — that is, Nepomuk and the content indexing. In particular it brings in Soprano and Virtuoso that have been among the least usable components when KDE4 was launched (at least Strigi is gone with 4.10; we’ll see what the future brings us). So after a night rebuilding part of the system to make sure that the flags are enabled and the packages in place, today I could try KMail.

First problem — at the first run it suggested importing data from Thunderbird — unfortunately it completely stuck there, and after over half an hour it went nowhere. No logs, no diagnostic, just stuck. I decided to ignore it and create the account manually. While KMail tried to find automatically which mail servers to use, it failed badly – I guess it tried to look for some _imap._srv.flameeyes.eu or something, which does not exist – even though Thunderbird can correctly guess that my mail servers are Google’s.

Second problem — the wizard does not make it easy to set up a new identity, which makes it tempting to add the accounts manually, but since you got three different entries that you have to add (Identity, Sending account, Receiving account), adding them in the wrong order gets you to revisit the settings quite a few times. For the curious, the order is sending, identity, receiving.

Third problem — KMail does not implement the Special Folder extension defined in RFC 6154 which GMail makes good use of (it actually implements it both with the standard extension and their own). This means that KMail will store all messages locally (drafts, sent, trash, …) unless you manually set them up. Unlike what somebody have told me, this means that the extension is completely unimplemented, not implemented only partially. I’m not surprised that it’s not implemented, by the way, due to the fact that the folders are declared in two different settings (the identity and the account).

Fourth problem — speaking about GMail, there is no direct way to handle the “archive” action, which is almost a necessity if you want to use it. While this started with GMail and as an almost exclusive to that particular service, nowadays many other services, including standalone software such as Kerio, provide the same workflow; the folder used for archiving is, once again, provided with the special-use notes discussed earlier. Even though the developers do not use GMail themselves, it feels wrong that it’s not implemented.

Fifth problem — while at it, let’s talk a moment about the IDLE command implementation (one of the extensions needed for Push IMAP). As Wikipedia says, KMail implements support for it since version 4.7 — unfortunately, it’s not using it in every case, but only if you disable the “check every X minutes” option — if that is enabled, then the IDLE command is not used. Don’t tell me it’s obvious, because even though it makes sense under some point of views, I wasn’t the only one that was tricked by that. Especially since I read that setting first as “disable if you only want manual check for new mail” — Thunderbird indeed uses IDLE even if you set the scheduled check every few minutes.

Sixth problem — there is no whitelist for remote content on HTML emails. GMail, both web and on the clients, Android and iOS, supports a complete whitelist, separate from everything else. Thunderbird supports a whitelist by adding the sender to the contacts’ list (which is honestly bothersome when adding mailing lists, like in my case). As far as I could tell, there is no way to have such a whitelist on KMail. You either got the protection enabled, or you got it disabled.

The last problem is the trickiest, and it’s hard to tell if it’s a problem at all. When I went to configure the OpenPGP key to use, it wouldn’t show me anything to select at all. I tried for the good part of an hour trying to get it to select my key, and it failed badly. When I installed Kleopatra it worked just fine; on the other hand, Pesa and other devs pointed out that it works for them just fine without Kleopatra installed.

So, what is the resolution at this point, for me? Well, I guess I’ll have to open a few bug feature requests on KDE’s Bugzilla, if I feel like it, and then I might hope for version 4.11 or 4.12 to have something that is more usable than Thunderbird. As it is, that’s not the case.

There are a bunch of minor nuisance and other things that require me to get used to them, such as the (in my view too big) folder icons (even if you change the size of the font, the size of the icon does not change), and the placement of the buttons which required me to get used to it on Thunderbird as well. But these are only minor annoyances.

What I really need for KMail to become my client is a tighter integration with GMail. It might not suit the ideals as much as one might prefer, but it is one of the most used email providers in the world nowadays, and it would go a long way for user friendliness to work nicely with it instead of making it difficult.

Today in Gentoo’s KDE land

And here I am, blogging about a a long day that made me feel so tired I’m knocked out on my bed, longing for reading some Peanuts strips. Today was almost entirely dedicated to KDE, so here I’ll try to point out the changes.

The first and surely biggest difference comes into KPDF handling. If you didn’t know, up to today we used a patch originally coming from KUbuntu and JRiddell, to make it use Poppler. The reason for this were that integrating xpdf code in KPDF meant having to bump it multiple time per release every time a new XPDF vulnerability was discovered (and this still happens, one was discovered just last week), and often we were already late on the patches train, plus the slowdown coming from arches taking time to mark stable, and at the time there was little or no downside to do this: no feature loss, and very little incompatibilities quickly fixed.

Today I was contacted by pinotree of the KDE team, KPDF developer, asking me again if I could drop the patches or at least add a vanilla useflag; I say again not because he asked me before, but KPDF’s main developer tsdgeos, criticised both us and KUbuntu a lot because of the patching, although at the time there were very little problems; this time I started thinking over this a bit more.

Many things changed since we started applying that patch: the focus on XPDF is now less than before, because Poppler already passed through most of the code, which means that the most stupid vulnerabilities were found already, there has been some little feature loss in the 3.5.7 version too, because the title of the postscript file queued for printing couldn’t be kept while using Poppler, and newer versions of Poppler also started behaving slightly differently from before, to the point that there are some major problems. Also I got a report of another PDF that is showing fine on KPDF’s code, but leaks memory when used on Poppler; outside that, Ioannis joined the KDE team, which is no more just me and Carsten, and I got kde-packager access, which means I can see the vulnerabilities as soon as they are discovered rather than when the advisory is released — You might not tell, but this is a great improvement. Pinotree also agreed to inform me, if possible, as soon as they discover something that has to be fixed, so that I can respond to it as soon as possible.

With the current situation, it was time to test an alternative. Right now there are two new revisions of KPDF in the tree, 3.5.5-r1 and 3.5.6-r1, they both are the same as their -r0 predecessor, but without the Poppler patch; in the case of the 3.5.5 version, also the security fix is applied. They should resolve quite a bit of problems, and they should be clean without further security issues up to now. Please test them, and report any possible issue you find. I haven’t applied the same to kdegraphics, because that’s way more massive to compile, so I left that one using the Poppler patch to have a single point of failure.

If you didn’t get the news, it’s no more true that split and monolithic ebuilds have the same exact features: as no developer seems to care enough for those, I’ve been merging to them only important changes and fixes, while I apply experimental or improvement patches to split ebuilds, or I remove them, like this time. I already did that with Lubos Lunak’s xinerama patches that are available on kwin and kdesktop but not on kdebase. Which means that if you want upstream support for KPDF, you need the split ebuilds.

Another drift between the two versions is with kdepim, that today, beside a revision bump to apply two hotfixes to KMail coming from its developers, lost the pda useflag for the monolithic version. The reason for this is that the new KPilot requires a pilot-link package that we don’t have, and thus I had to mask it entirely, until someone in PDA herd can get a hold of that. In the mean time if you need KPilot you need to use KPilot 3.5.5 and kdepim-meta.

Even more changes: KDVI got an emacs useflag, thanks to Sebastian Shubert, to enable search forwarding to emacs. I hope I got it right though, it’s the first time I add an emacs useflag to a package, I never used elisp.eclass before.

And again with something important, KDevelop 3.4 is in the tree, the new branch with about 500 closed bugs against the older 3.3 branch. This version not only features fixes by upstream, but also got the correct configuration for our ctags (named as exuberant-ctags), so that new installations will have it working out of the box (I maintain that packages that requires configuring tools’ paths should be pre-configured by ebuilds so that users don’t have to change them manually). Old installations will unfortunately have to fix the path from the configuration if it’s not already set correctly, sorry for that, I’ll be working on it maybe.

And for external software releases, Tom Albers released Mailody 0.4.0_rc2, that is also in the tree: his lightweight IMAP client improves with every release, with this series it also got signature support. I’ll probably use it as my main client on Intrepid’s installation, rather than KMail; after all right now I don’t have GPG support in either Operating system. Basically the only thing stopping me from using Mailody as my main mail client everywhere is GPG support… but I trust Tom to get it sooner or later :)

Another release, but this time not yet in the tree, has been TorK 0.13; unfortunately when I tried, it didn’t work; but Robert diagnosed the problem right away: this version requires the alpha development version of Tor, which means it wouldn’t work with what we had in Portage till now, but Gustavo (HumpBack) now committed under package.mask a new alpha version of Tor that I’ll depend upon tomorrow, when I’ll commit TorK 0.13, also under package.mask.

Another thing I’ll have to fix tomorrow even if it would be part of Gentoo KDE’s day, is the new handling of XDG environment variable on system level rather than KDE session level: Christoph Brill reported it and Pacho Ramos found the problem yet again :) One of the two variables is misplaced, and should return to be a session-only variable; I’ll fix that first time tomorrow.

This should cover all the work done for KDE today, and it’s not bad, I have to say. Of course, I also spent some time on Serielle Konsole: last night I was able to finally get it working almost perfectly and configurable: now by default it starts with a session opened on /dev/null – to avoid keeping a device that shouldn’t be opened – and you can start a session to a given device with given parameters by configuring a session, in the same way you configure the sessions for standard Konsole! The configuration of the schemas, the extra icons, the wallpapers, and the terminal profiles are also shared by the two, to the point that one of Serielle Konsole’s dependencies will be for sure Konsole.

I plan to add a few more things before the first release, like a command to send the Break signal (already present in the code, just need to be shown on the menu, on the popup, and get a shortcut assigned), support for resuming Serielle Konsole from a saved KDE session with the devices as were open before – like Konsole does for the directories – and a way to specify on command line the device to open (this was on request by Marco Gulino, who would like to use it for KMobileTools debugging :) ).

Now I could be talking about Amarok, about xine-lib not crashing anymore when you try to open a smb URL, about the new VLC snapshot in Portage from the bugfix branch of the guys at VideoLan, about my plans for ALSA in the next future and the new breakages introduced in 2.6.20 kernel and later, but I’m too tired and I’ll leave most of that for tomorrow. I’ll have a full day again.

Goodnight everybody, and enjoy today’s, tomorrow’s and next month’s fixes, so that I don’t apply them for nothing ;)

Sometimes blacklists are bad

I blog this quite late as it happened to me yesterday, but that was a long long day and I forgot to do a lot of things.

One of the things that pissed me off yesterday morning when I woke up was to find mails from OpenOffice’s bug tracker, and from a contact for a new job put in the Junk folder.

A quick look at it told me that the problem were the URIBL_*_SURBL checks from SpamAssassin, giving high rates to almost every address possible, present in the mails, included openoffice.org and firebirdsql.org.

The first thing I did was to set this in my local.cf for spamassassin:

score   URIBL_AB_SURBL  0.0
score   URIBL_PH_SURBL  0.0

but then I got the mails garbled by spamassassin’s safe report.. took me a while to find in spamassassin -d the correct command to kill that extra data written during the check.

So, why am I blogging all this? Well, to give an hit to the KMail users: if you set up SpamAssassin integration in KMail you got a “Filter Classify as NOT Spam” action to run on mails, that by default only uses sa-learn to bias the bayesian filter; if you go in “Configure Filters” from the “Settings” menu, you’ll find the configuration for that action; add a new entry on the filter actions “Pipe Through” spamassassin -d; now, every time you mark something as NOT spam even when it has been filtered through spamassassin already it will come back to its natural shape.

And this is it for this week’s issue of Flameeyes’s microscopic tips & tricks.

Little annoyances

Now that KDE 3.5.5 is done and ready, I was thinking of some little annoyances that I’m having and that I’d like to get rid of as soon as I can, for my mental sanity mostly.

The first of them was the Doxygen support in Emacs through doxymacs. after two weeks waiting for tempo’s homepage to come back up, I’ve found that it is already present in Emacs, just like W3 is for the CVS version, so I didn’t need to bother with that.
Unfortunately it still does not work as expected: while it highlight as intended comments in Qt style (/*! */), it does not work as expected for JavaDoc-style comments (/** */) that are widely used, more than Qt style for sure. I’m not sure why this, and how to solve it :(

Another annoyance for me comes from mailing lists like LKML, that are so big I cannot really follow them entirely, and that ends up overwhelming me. I used to follow such mailing lists with FreeAgent when I used Windows (back in the days), but I haven’t found a good alternative for it… KNode sucks too much, as it does not resemble KMail in any way on the interface, it does not support the same way of signing/verifying the email, and it does not goes into try “waiting”…

As KMail seems to have fixed the issue with ignored threads not getting set as read already in IMAP, I’m reconsidering using KMail (with a specially created mailbox). The problem is that it’s slow to purge old messages, I’d need a way to clean them up, and mark the old as read, directly on the IMAP server, or on the maildirs themselves.

Oh well, I suppose I can leave with some quirks myself, especially considering that’s for my job :P

In the land of KDE…

Okay, I ended up with the cool titles for blog entries, I know. This entry is supposed to be a mix of stuff related to KDE, thus the name.

Let’s talk a bit about KDE, that is my desktop environment of choice (I’m one of the lovers of the “full-fledged environment”, so I don’t like minimal stuff like FluxBox and similar; what some people call blot, I call integration, and I like it), and that should have been clear for a while now. Together with Blind Guardian, KDE is probably one of my favourite German products :)

First of all, I want to express my congratulations to Sebastian Trüg, author of K3b, that’s doing a pretty neat job, creating one of the most complete burning interfaces I ever seen. His contribution to the Linux desktop is way more useful than the continue bitching of cdrtools author Shilling. If you can stand experimental software, I’d suggest you to try the 1.0_beta2 release currently in portage, it’s awesome.

Unfortunately, there’s a problem with this: this version, probably for solidity checks, disable the mediamanager service in KDE, and Amarok 1.4.2 and later uses the mediamanager for the “dynamic collection” setup; if you have Amarok open while burning, you end up with the collection disabled and a lot of features missing… don’t worry, just close and reopen it and it works. I’m sure the Amarok team is going to fix this problem before K3b 1.0 is final, or at least they’ll try… right Mark :)

While I’m really liking most of KDE development, and I really hope that the new #kde-ruby channel on freenode will bring more Ruby developers on writing KDE applications, as thanks to Richard Dale it’s possible to actually have perfectly integrated KDE applications written in Ruby rather than C++ (which allows a quite different approach to the whole development, gone the dead time needed to build, or rather to link, the code), there are a few things that I still don’t like, and I think would need a better development, or actually some kind of development. Unfortunately my time constrain don’t allow me to try to improve the situation, but I put my hopes in KDE 4 :)

First of all, the KRDC/KRFB pair, client and server for desktop sharing via VNC protocol (and frontend for rdesktop, RDP client), seems to me like they are ignored a bit too much. The client does not work that well with xinerama, it loads full screen automatically, but appears only on one of the screen, sized like it was stretched in two, so you see only half o the window, you have to reduce it to window to use it on a xinerama-enabled setup. The server instead, using a very old version of libvncserver, and missing support for most of the recent interesting features of XOrg, it’s slow to the ridiculous when compared to something not that different like x11vnc. The only good thing the two of them have is the service discovery support, but they don’t seem to support zeroconf/mdns protocol, that seems to be what most of the software is standardising toward (thanks also to Lennart’s Avahi – that I criticised and still criticise from time to time but it’s proving the most stable between the choices we currently have, too bad DBus is still behaving strangely on FreeBSD without being patched and thus we can’t use it there yet :/); similarly, x11vnc does supports neither of them, which loses one feature, but not a core one (speed beats service discovery).

Then I still don’t feel that comfortable with Kopete; for some reason the latest update broke MSN filetransfer for me at least, and KMail doesn’t seem to improve on the memory usage side nor on the crashy side… Plus, I don’t really like their way to handle bugs, I submitted one once (stating that some e-mail addresses were incorrectly reported as wrong when they were correct, just strangely formatted), and providing a patch that rewrote the address parser to use regular expressions rather than manual parsing, as a try… when you get told to fix their code, and not rewrite it, if you want the bug fixed, you can be a bit pissed off, I think (especially since they didn’t fix the issue, it’s still there).

So my bottom line is, that I hope KDE4 will try to focus on fixing these problems, rather than going on with “usability audits” (that often result in stuff nobody but the usability people like) or with Windows portability (fine if someone wants to take care to port it, not fine when you hinder the development to re-focus it on Windows portability). I really look forward for KDE4, cmake or not, and I really hope these issues can be fixed.. or that with Korundum we can write a better mail client than KMail ;) Maybe writing Tinymail Ruby bindings would help…