- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
KMail Frustrations
I have been a great fan of the KDE desktop from days of yore, and I consider myself to be quite versed with its workings but since I am not a KDE developer (I do Qt though), my KDE knowledge is largely from a user perspective. A few months back I switched from Thunderbird to Kontact, because it offered a unified PIM solution which I considered to be great. The days of relying on disparate extensions to achieve simple tasks was gone.... or so I thought! |
|
Comments (17)
bad approach
I think that may be the biggest reason I've gone the Trinity-DE route: Of all the functions that have been rock-solid stable for DECADES, it's the email client address book.
And somehow, for some reason, KDE4 has messed that up.
In the immortal words of Chandler Bing, "Why-wh-wh-why-why-WHY???"
Migration
Second, the last 2 days I spent on migrating from KMail/KDE3 to Thunderbird -- you know, the most popular open-source email client, well-polished and so on. No way to customize keyboard shorcuts (I am talking about core program), BROWSER setting not recognized, clipped all text entries (lower several pixel of every text displayed), no way of set the font size and colors (compare this to KMail capabilities), and so on and on. Generally speaking, ability to customize the program is very narrow.
So I got back to KMai/KDE3. I don't want to use KDE4 version because of all the problems you mentioned. It appears KDE3 was and is the best suite because the number of problems are at minimum.
It is good luck, KDE3 is still available for opensuse 11.4 as ready to install packages and I just wonder for how long we will have to use KDE3 because there will be only some kind of sick competition...
Trinity-DE, the fork of KDE3, is alive. It works, and I use Kmail-trinity every day successfully.
Claws-mail also looks good, from my investigations, if you want something stand-alone.
openSUSE KDE Team responds
> I am still stuck with 11.2. So when I got a little time on my hands recently I decided to grab me the latest KDE.
First a disclaimer: 11.2 is approaching the end of its life (May 12 2011) and while we do provide the latest KDE packages for it (http://download.opensuse.org/repositories/KDE:/Release:/46/o...) we don't test or provide any guarantees that it will work. I recommend using a recent, tested distribution release if your troubleshooting techniques only extend as far as writing angry articles.
> To my dismay KMail was complaining about unresolved dependencies! KMail wanted Akonadi (does that sound like anaconda to you?), which in turn required Nepomuk, which wanted MySQL... Darn!!!
What method did you use to install KMail? openSUSE Build Service packages? From source? All these dependencies are well known and the standard tools, YaST or zypper on the command line, will install them for you along with KMail.
> I was not... and will not.. allow my email to reside in MySQL.
This is your first mistaken assumption. Newish versions of KMail and Kontact use Akonadi which in turn use a database as a data *cache*. This is not its permanent store - the data still lives in maildir/vcard/ical folders. This allows KMail itself to be a simpler app and concentrate on the presentation of email.
> because I use MySQL (and PostgreSQL if that matters) for so many projects and I often change the Data Directory (datadir directive in /etc/my.cnf) depending on the project I am working on. While I could accommodate a PIM database within a project, I was not sure what would happen when changing from Project A to Project B.
You're overthinking this too. The KDE PIM team know that a mail client should work out of the box. If you look in the process list with a running recent KMail you'll see something like this:
usr/sbin/mysqld --defaults-file=/home/<USER>/.local/share/akonadi//mysql.conf --datadir=/home/<USER>.local/share/akonadi/db_data/ --socket=/home/<USER>/.local/share/akonadi/socket-emsig/mysql.socket
As a heavy MySQL user you'll recognise that the MySQL instance used by Akonadi is started with a custom datadir and config files, and communicating over a dedicated unix socket. It won't ever conflict with your project MySQL instance(s).
So in response to your summary:
> What were they thinking?
To design a common PIM data middleware layer replacing many error-prone per-application caching solutions
> Why did they not use SQLite which in my opinion would have been best suited for such a task?
An option (used by default on the mobile ports of Kontact)
> Why did they not provide an easily configurable mechanism of achieving what was required?
As shown above, they did.
> Why did they assume that I would have MySQL installed?
They don't have to - this is your distribution's responsibility. And our standard tools ensure this.
> Why should installation and configuration of an email client be as taxing as if it were an ERP? Why? Why? Why?
Most users' experience doesn't match yours, so I guess that a) you were using some non-standard tool to install latest KDE that doesn't handle dependency resolution and b) you then saw "MySQL" and prejudged it based on your own experience of MySQL.
What will be next? A cluster needed for doing search?
I know (as developer) the need for good separation of the programs, but here is example of the overkill. One should keep things as simple as possible, but not simpler. MySQL used for caching (what data, mail?) is not a tool "as simple as possible".
No wonder, with all fast computers we are not more productive because of all hevy-weight processes running in the background and slowing down overall performance. Not mentioning bizarre UI approach (in general; here I have just a few complains for KMail).
You can of course reason why this or that decision was made, but I see the outcome and it is no-go for me. Maybe at some point new KMail will be as good as its KDE3 version, maybe not -- it is not up to me, but it is up to me to choose the best one. For now it is KMail/KDE3.
Many thanks for replying. I think many users have questions about MySQL / KMail (and hence why it's in the FAQ).
On behalf of the LXer editor-team I'll put a line at the end of the story linking to your answer above.
On a personal side note, is it correct newer versions of KMail default to SQLite? During update to kde-base/kde-pim-meta-4.4.10 on Gentoo (using standard portage / ~x86), in one of the configuration files in /etc/ I noted MySQL was replaced by SQLite, does that it's using SQLite now?
That's not correct. The upstream default for Akonadi for desktop KMail/Kontact is MySQL. For mobile Kontact it's sqlite. I assume Gentoo has changed that setting. The background story is that when Akonadi started there were severe performance problems with multi-threaded sqlite; however there was no way, even with the aggressive slimming down used in the desktop configuration, to make MySQL fit onto WinCE 6, so the team fixed some sqlite problems and found workarounds for others. This makes sqlite a viable option on the desktop too, although MySQL or PostgreSQL perform better.
What is the advantage to the end user of breaking Kmail into chunks and spreading it over all these weird subsystems? All I see is more drain on system resources, more complexity, more things to break, and more difficulty for users to ever understand, debug and correct their own systems. Certain tasks need to be done whether they're included in Kmail or shifted to something else; there is no free lunch.
Since binary indexes are a problem, and that seems a weird design decision in the first place, XML files like other mail clients use seem like a perfectly serviceable solution. I don't think it's users like macia who are overthinking.
Given I'm on a source based distro, I agree; you don't want to know how long it takes compiling KDE-PIM + dependencies. Have been using KDE-PIM since 4.2, and even while I'm now at 4.4.10, NEPOMUK still gives errors - like "not registering at dbus" and such. One gets used to it. Starting Koncact, clicking "ok" in the "error-list", downloading my mail and scanning it - using SpamAssasin's daemon spamd - usually takes multiple minutes. While scanning, Kontact is unresponsive. Maybe a bad SA configuration, I can't tell. Of course, 4.6-beta (or something like beta) is available now, but I don't trust beta software with my e-mail.
I was looking for an alternative as well, I liked your Balsa-recommendation (IIRC it was you who advised it). But I was not sure how to export my current mails to Balsa, and since those mails are crucial to me, I'm still stuck on KMail.
The question as to 'why' has been answered before I think: Currently it was pretty impossible for "PIM-like" programs to communicate between each other, so many ad-hoc dirty hacks were employed. I think the common middleware-libraries are aimed to solve this. Result is, the end-desktop user is left with software for which it's a requirement also to be able to run large groupware servers.
I understand the bit about needing a good PIM framework. I don't understand goofy stuff like Kmail cannot function as a standalone mail client without dragging in the entire akonadi/nepomuk/mysql framework, because Kmail is now only for "presentation of email", which seems to mean that functionality that used to be in kmail is now somewhere else, and Kmail is no longer portable outside of KDE4. Not without dragging in all this framework stuff that lives only in KDE, so now we're in the fun situation of both Gnome and KDE4 having redundant complex frameworks of all kinds, so they're farther apart than ever. And that running mixed systems means installing vast quantities of extra baggage, and maintainers of other graphical environments have to work harder than ever for what should be standard, boilerplate integration such as system menus and appearance.
It's like going to a restaurant for a hamburger and you get served a giant pot of beef stew. Where's my hamburger? It's in there, inside its cool new framework.
Eh, I suppose someday it will all get sorted out. The price of continual improvement, I suppose.
Quoting:you should be able to open your Kmail stores directly in Balsa
"No, life can't be that simple. It's impossible. It's morally wrong. It's not the way it was designed. It's not the way the world ought to work. It simply won't compile that way. It will give me a selftest-dialog-box with 3 errors and 23 warnings with 12 clues of how to fix my my.cnf, configure the InnoDB storage log level and configure things through the systemsettings command, which of course I have to emerge first. There should at least be some added generic multiple framework specially crafted middleware incompatability layer to prevent said wanted behaviour, right?"
Thanks for helping me out!
Other than that, I owe many thanks to the KDE-PIM team, but I think the "one size fits all" doesn't fit me anymore. It was great while it was a fast way to check / read my mail and didn't bother me with error listings, but after two and half year (wow, have I been on KDE4 that long already?) of keeping up with it I'm afraid I'm moving on. And maybe come back when KDE-PIM 4.6 is stable.
In the mean time, I might try to compile the 4.6 version just to test it and maybe help with error reports, but I'll keep it separated from my valuable mail.
In Balsa you can open any MH, mbox, or maildir by right-clicking in the folder view and then click on New, which opens a filepicker. ./balsa/config is simple and understandable just like config files are supposed to be.
the fix..
I was also having this issue and after several hours I have found the solution:
This is for openSuSE 11.4
1> enabled mysqld: yast2> System Services>> Start the MySQL database server = enabled
1.2> root@host: mysql_secure_installation (follow the directions, set a mysqld root passwd, Y to all others)
1.3> root@host: /etc/init.d/mysql start (at this point kmail / akanodi should work for regular users)
2> allow akanodi to run as root user:
root@host: echo "user=root" >> $HOME/.config/akonadi/mysql-local.conf
root@host: echo "user=root" >> $HOME/.local/share/akonadi/mysql.conf
2.1> test it
On openSuSE 11.3 had same issue (but wasn't try as root) there I setup mysqld as above, start kmail as user, but still failed.
The fix was to reinstall the mysqld package, then it worked fine.
Serapis
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Sign up and post (it is free) or Log in and post