Advanced

A KMail Breakthrough.

Posted by Ridcully on May 1, 2016 4:57 AM · 37 comments
LXer Linux News; By Dr Tony Young



LXer Feature Update: 27-Apr-2016

This tells the story of how I finally managed a successful transfer of email data from KMail version 1.13.6 to version 4.11.5. It is a non-technical essay exploring the obstacles I encountered, my options, and the methods I used to achieve my aim. It was written partly to give the information, but also with the hope that readers will both enjoy and be amused by the story of the "battle of KMail" that was ultimately won against "incredible odds". Links to the earlier articles discussing problems with KMail 4x are given at the end.

Introduction

This article has come about purely because I was downright stubborn - and that is putting it mildly. My current laptop is an old HP Compaq 6710b with a 2-core processor, running a 32 bit Linux system comprising openSUSE 11.4, KDE4.6 and KMail version 1.13.6. Yes, it's antique, but if it does the job that I need, then fine.....if it ain't broke, don't fix it. Unfortunately, while not broken, this dear old laptop is now beginning to really show its age....silly things like keys that may not always work at the moment you need them, or speed, or versions of software that are simply too old to do the job really well any more; just minor irritations, but they all add up.

Last year, I undertook a project with a software development group in Brisbane, and in order to do the work necessary, a new 64 bit laptop was required, so ultimately I found myself the proud possessor of an HP Elitebook 8540P (64bit, 4 core) which was running Windows 7 when I got it. Allow me to confess immediately, that the laptop was NOT brand new......it was a second hand ex-government laptop but in "as-new" condition. And the reason I insisted that it come with Windows 7 was that I knew, for my own ease of use, that the computer would be running the traditional BIOS software chip and therefore I would not have to fight with UEFI. I also made sure that I was able to replace the hard disk drive easily, and that meant that I could remove the Win7 drive and replace it with a blank drive ready to receive Linux. Before someone steps in and says: "Dual Boot", I have never operated that way and don't want to. My preference is to swap the hdd's, and because I know exactly what to do by swapping drives, I prefer to continue that way.

With a blank hdd in place, I loaded the new laptop up with openSUSE 13.1 and proceeded to "play". I chose 13.1 because it is the version that will be supported by the Evergreen project and so 13.1 will retain support for about another two years after SUSE itself stops support. I tried a number of things to get the KMail email files from my old laptop into KMail in this new 64bit machine and in the process of which, altered some settings for KDE. Eventually I found real problems (which I won't discuss here), decided to dump the lot and erased the drive. I then decided that perhaps version 13.2 would be better. Within an hour after installation of 13.2, I regretted that move so much that I once more erased the drive and re-installed 13.1. I also promised myself that under no circumstances would I tamper with any settings involving Akonadi, and I would alter only the minimal ones required to get KMail on line. From then on, I would just simply see what happens when various techniques are tried.

Finally in this introduction, let me say this. I strongly prefer KDE as my workplace and even more strongly prefer KMail as my email client software. I am at home with KDE and I use both the classic menu and the folder view. Once you have those in place, KDE4 closely resembles dear old KDE3.5, but KDE 4 is a far better piece of software apart from its enforced dependence on Akonadi for the "Personal Management Suite and KMail" set of programs - well, that's my opinion. Also, I am now a dedicated Dolphin user as regards file management. I very much like its settings abilities and its split screen mode is wonderful. I'd hate to be without it.

However, in my humble opinion, while KMail is an excellent email client with a superb display, it has been made overcomplex and it can be an absolute "stinker" to work with while you are setting it up if you have never used it before. If you know where to go, you can get the settings for classic style, flat date layout, folder view down the side, etc., but it is exceptionally easy to end up with an extremely messed up display and a "difficult to use" program if you put in the wrong workplace view settings. As for its Akonadi dependence (the Wallet problem appears to have been fixed), words almost fail me as regards this disgusting set of affairs. I retain precisely the same very adverse perceptions that I fully documented in a series on KMail published on LXer a year or so ago. Nevertheless my preference for KMail was such that I soldiered on stubbornly and tried to get this newer version to do what I wanted - and that was not necessarily what the KDE4 and the KMail teams had unilaterally decided all the users wanted. You have to love that arrogance - remove the user's choice fellers, that's the way to go in Linux - NOT !.

Getting the Mail Files Across from KMail 1.13.6 to KMail 4.11.5

The problem seemed insurmountable. KMail 4x can do a simple import of a previously prepared KMail archive file which will contain all your emails and settings etc........BUT.......the much, much older and earlier KMail 1.13.6 does NOT have the ability to archive its files, and therefore you cannot export an archive to be taken up by KMail 4x. So, could you do what used to be so simple with all versions of KMail up to KMail 1.13.6 ?

All you did was make a complete copy of the kmail directory in ..../.kde4/share/apps/kmail/ and drop that kmail copy into the same location in the new installation........KMail immediately recognised all files, folders etc. and away it went. Simple huh ? But you cannot, cannot, cannot do that now.

I can tell you that thanks to the fact that KMail is now integrated with Akonadi, an SQL based server, the email files are apparently saved as part of the Akonadi resources in the location: ....../.local/share/akonadi_maildir_resource_0. But it gets better. If you open that folder, you will find the folders you have just set up on KMail 4x and inside each are the usual "cur", "new" and "tmp" folders. However, my inspection showed that there seems to be a random logic in whether or not the files shown on the KMail display are in any of those folders, or none. Further, that mail directory location is set up as an Akonadi resource, and although it can be handled by the file manager, it does not correspond to the older KMail Unix file system resource. My experience so far strongly suggests that unless an email has passed through the KMail software itself, Akonadi will not know it is there and in turn KMail depends on Akonadi for its recall of email data. I decided that sleeping dogs were best left lying and that discretion was the better part of valour - there had to be an alternative.

(Note: Sadly, what I have written in the paragraph above suggests to me that unlike KMail 1.13.6, where you could so easily use your file manager to make a flawless copy of all your emails perfectly arranged in their respective folders, KMail 4x prohibits this situation. I hope I am wrong, but so far nothing has changed my mind. I suggest some options later.)

Evolution Gives the Answer

It shows how stubbornly frustrated I was getting with the situation in that I also tried two other email client programs, Thunderbird and Evolution. Neither of them appealed to me as much as KMail, although I suppose with time and knowledge and familiarity (especially the last) I am sure I could have grown to enjoy both. In my very early years with Linux, Evolution was my main email software, but that is going way back to around 2003. However, it was Evolution that gave me a key to the problem and it is sad that I cannot acknowledge the writer of this short article, because the name hasn't been included. I had searched on methods of getting KMail files into Evolution, and here is the result that finally "opened the door":

https://eyemeansit.wordpress.com/2011/03/03/migrating-from-k...

As you will see, if you open the article, it is a tutorial which explains the series of short steps that you need to take in order to export the file contents of email folders in KMail into mailbox files (.mbox) that can be imported directly into Evolution. I am not going to repeat the tutorial steps here; they are very clearly written and extremely easy to follow. So, could my old copy of KMail actually do this export ? The answer was very rapidly, "YES", and the process followed the exact steps described in the tutorial written by "eyemeansit". I created a folder called "tempmbox" and eventually I ended up with 23 ".mbox" files of varying sizes which corresponded perfectly to the contents of the 23 folders in my old KMail 1.13.6 software. Naturally, each mbox file was named so that I knew the name of the new folder that would need to be created in KMail 4.11.5, eg. "Crossover.mbox". And of course, there were mbox files corresponding to "inbox.mbox" and "sent-mail.mbox". Okay, that now had things to the point where every email currently held in my old version of KMail had been exported to a series of mbox files that would (or should) be instantly recognisable by both Evolution and hopefully, much later versions of KMail.

Importing into KMail 4.11.5

The next part of the process is tedious, but reasonably simple. You should create the additional folders you need by selecting "Local Folders" in the side panel of KMail 4.11.5, then right click on it and select "Add Folder". It helps if you also have the temporary folder with all the mbox files open in Dolphin (or your preferred file manager) and you can go through that file list one by one while you are adding the names of the KMail folders so that each relevant mbox file will eventually be sent to its same folder name in KMail. Once that is done, you will have your new version of KMail with a set of ready and empty mail folders. I mention here that when importing the .mbox files into KMail, you can send an mbox file into any KMail folder you wish to choose, but in this case, the aim is to duplicate the structure of the original KMail layout.

Now select "File" on the menu bar, and from the drop down menu, select "Import Messages". This will open a subwindow like the one below which was taken from my present installation of KMail 4.11.5. Next, you need to open the selection panel at the top and make sure that the choice of "Import mbox Files (UNIX, Evolution)" is selected from the drop down list. It's right near the top.

{Special Note: it was while editing and checking this article, that for the first time I looked at ALL the options available for importing into KMail 4.11.5, and about halfway down the long list, came across this little gem: "Import KMaildirs and Folder Structure". It may seem odd, but I had never noticed it before because I was searching for an Evolution solution and that option is found virtually at the top of the drop down list - therefore I didn't look further. I have no idea if this option will work correctly on the older KMail structures but at least I do know for certain that the mbox option does. Also, I can only wonder why this particular option specifically for KMail is not at the very head of the list. However, I digress.....back to the battle.}

Next, from the bottom selection panel, open the selection dialogue and select the particular folder in KMail you wish to import email data into. It is at this point that ensuring the names of the mbox files correspond to the KMail folder names makes your task very, very easy. Once you have selected the particular KMail folder into which you want to import data, select "Next". A new subwindow will open which will allow you to select the relevant mbox file.



From here on, just follow the instructions and you will usually be astonished at how fast the process works. You will end up with all the relevant emails from the mbox file imported into their correct KMail folder - sort of; see the next paragraph for the last little "tweak". Doing this procedure again and again is slow and tedious compared to importing a single archive file, but it works. It is quite possible that all the inbox emails will be marked as "unread". If this is the case, then an even more tedious job is waiting for you, because as far as I know, you have to select the files one by one so they are marked as read.

There is also another minor and tedious task to be undertaken. Each time you import an mbox file into the KMail folder, it does NOT go immediately into the folder itself, but instead the emails are copied into a subfolder of the folder you are working with. What you then do is open that subfolder, select all the emails in it and "drag and drop move" them into the designated folder and delete the subfolder. Okay, messy, but once again, it does work.

Last But Not Least.

As I indicated above, there seems to be no way you can drop a Unix based copy of the entire set of KMail files into the present version of KMail using the standard file managers. I'd be enormously happy to be corrected if I am wrong in this matter. As I presently see it, there are two methods available to the KMail user if some sort of backup system is to be applied - there may be others. The first is to use the "mbox" export method and keep that set of files as an "unreadable but savable" copy. The second is to use KMail's archive process and make a standard archive.

I'd also stress that this article contains my perceptions of the situation as it unfolded. There are probably other ways of doing what I wanted, but I found a way to effectively solve a problem and tedious or not, I'm very content with the results. It is very possible that some of my assumptions are incorrect and readers should recall that I am just a user who has fought his way through a problem and seen it from a particular perspective. I'm very happy to be told of any errors I've made in this text, just as long as I also get the real answer.

At the moment, KMail 4.11.5 seems to be running perfectly. I have altered no settings which concern the Akonadi system. I cordially detest the fact that KMail is wholly dependent on Akonadi, but I don't dare touch any of its default settings for fear of rendering KMail inoperable. I have no objections to Akonadi itself, I simply believe that users should have the choice/option of operating KMail completely independently from Akonadi and preferably with Akonadi wholly disabled.

I have gone through some "convoluted process" which seems to have stored the server password in KMail rather than the wallet, but if you ask me how I did it, I simply don't quite know. Just luck that I pushed the right buttons, I think. I do recall that when the Wallet kept on asking me if I wanted to Keep the password in the system, I selected Keep each time, and I think the Wallet got sick of asking. What I do know, is that when I just looked at my account, the password is clearly shown as having been registered in the KMail software itself. If that is the case, then I congratulate the KMail team for restoring that user option - I repeat, my only problem is that I don't know precisely how I did it. I have always argued that a user should have the option of either keeping the password either in the system or in the Wallet, and the option should be very clearly displayed.

Assuming that the option to use or not use the Wallet has now been restored, KMail's absolute dependence on Akonadi to store its files remains the sole major problem as far as I personally am concerned. But for the rest, KMail remains a superb piece of software, settings complexity or not - I can live with that. And one last thing is that the 4-core 64bit laptop runs both KDE 4 and KMail very fast indeed and at least some of the problems noted in the earlier articles are now un-noticeable.

So there we are.......I think I have managed to "bash" KMail 4.11.5 into a form that I can use comfortably. It's been a very steep learning curve and I wasn't sure I was going to win. To be honest, I think the KMail team would be perfectly justified in saying that I should have expected some sort of difficulty in trying to migrate emails from such an old/antique version into one of the latest versions. And I cannot help but agree - but in mitigation KMail team, I believe I used an "antique method" to get my files across (sorry, but that strikes me as funny). I have noted that the Accounts section in the setting up window has a "Local Mail" line......I'm not sure what it does, but it's of no use to me, and so I have left it strictly alone. Like other parts of KMail now, I am reluctant to try to modify or delete areas about which I lack information and whose change might disturb the smooth running of the software in some way.......What an absolute pain. But, thankyou once again KMail team for the Password/Wallet option alteration and the difficulties that were laid in my path (and I strongly emphasise that I am not being sarcastic at this point). Without those problems, I would not have explored and learned about the mbox concept - and best of all, it worked.

Links to the Earlier Articles on openSUSE 13.1, KDE and KMail

Here is a link to my earlier article discussing problems with KMail in these latest versions. I'd add here, that later events have "killed" the Patience option described here. The latest versions of KDE4 have been modified to the extent that the old version of Patience will no longer run. Sad. The new swinging and dancing version of KDE 4 KPat does NOT have the crispness and quality of the card decks available in the old KDE3.5 KPat. Well, that's my opinion.

"KMail Complexity - and a Little Patience": http://lxer.com/module/newswire/lf/view/197664/

Readers might also like this other series on openSUSE, KDE and the semantic desktop. The links to both Part 1 and Part 2 are supplied.

Removing/Disabling The Semantic Deskop in KDE4 (and firing up Thunderbird) Part 1

http://lxer.com/module/newswire/view/198081/index.html

"Removing/Disabling The Semantic Deskop in KDE4 Running on openSUSE 13.1 Part 2"

http://lxer.com/module/newswire/lf/view/198639/

Return to the LXer Features

Comments (37)

VLC and Xine in openSUSE 13.1

1 earlier comment in the full thread.

One tip would be to repeat the test with both apps started from the command line in a terminal. Then you might have some diagnostic messages left in the terminal after the abnormal shutdown. The messages might shed some light on the cause.
I strongly suspect this may be a matter of getting hold of the proprietary Intel driver. There's usually a way of doing so......but the matter isn't urgent at this stage.....it's like an itch on the back you can't reach. LOL. By the way, Penguinist, I had already tried your suggestion but the results meant nothing to me and I cannot remember what they were anyway.
It really doesn't sound like a video driver problem to me, per se. Rather, it seems like some sort of environment/app setting combined with a broken package. One way you can make a video player crash is to select the wrong video playback overlay setting (one that isn't supported by the driver as configured) in the app. Do what penguinist suggested and run one or more of the apps from the command line. You also want to run the commands shown here: http://askubuntu.com/questions/28033/how-to-check-the-inform... ... to get info on what driver is being run and with what configuration settings...
JaseP..........I finally got around to testing the situation out with 13.1. If you can understand what the terminal message means, I'd appreciate it. (I put lines of dots in place to try to separate the lines)



tony@linux-opzy:/usr/bin> vlc

...................

VLC media player 2.2.3 Weatherwax (revision 2.2.3) [000000000219c0b8] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.

.....................

WARNING: QApplication was not created in the main() thread. Segmentation fault

....................

tony@linux-opzy:/usr/bin>

Post Script.......I have managed to get a copy of Xine running......I used the rpms that were available on this site:

http://cambuca.ldhs.cetuc.puc-rio.br/xine/

You need all three of the libxine, xine-ui and libdvdcss.........once all three are installed, xine runs perfectly - with one teensy, weensy problem - no sound.
That's interesting.

Could you run that test once more with verbocity turned on please, and let's drill down one level little further.

Run in a terminal as:

vlc -v

Okay penguinist, here is what I get. I do apologise for the format, but this is how it comes out in the terminal:

tony@linux-opzy:/> /usr/bin/vlc -v VLC media player 2.2.3 Weatherwax (revision 2.2.3) [000000000105c0b8] core libvlc warning: cannot load module `/usr/lib64/vlc/plugins/meta_engine/libtaglib_plugin.so' (/usr/lib64/vlc/plugins/meta_engine/libtaglib_plugin.so: undefined symbol: _ZTIN6TagLib3Ogg4Opus4FileE) [000000000105c0b8] core libvlc warning: cannot load module `/usr/lib64/vlc/plugins/codec/libgstdecode_plugin.so' (/usr/lib64/vlc/plugins/codec/libgstdecode_plugin.so: undefined symbol: _gst_fraction_type) [000000000105c0b8] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. WARNING: QApplication was not created in the main() thread. Segmentation fault

Hope it means something to you.
Some one else reported this problem after an upgrade and said the following: "The problem seemed to be in messed up configuration (sorry I didnt save it). I removed the /root/.config/.vlc and everything started to work"

This was back in 2008, so it may not be the same problem, but I'd give moving that directory to a backup a try.
Just a note:

Terminal messages will appear correctly if you use the 'code' tag in your post.

Like this:

[...code...]


xyz@workstation:~$cowsay Hello Ridcully! _________________ < Hello Ridcully! > ----------------- ^__^ (oo)_______ (__) )/ ||----w | || ||

[.../code...]

Of course you will need to leave the ellipses out.

The 'code' tag is fairly equivalent to the html 'pre' tag... and allows one to display monospace text as intended preserving correct spacing as well as carriage returns.
Oh well... it seems that some of the spacing does in fact get screwed up... The spacing is apparently mostly preserved. However, the submitted post does not appear identical to the 'preview' post.
Quoting: I removed the /root/.config/.vlc and everything started to work"


Actually Ridcully is probably not running vlc as root, so his configuration is probably in

/home/tony/.config/.vlc


Deleting (or renaming) that and restarting vlc is probably a good idea. vlc will recreate it, this time possibly correctly.
Thanks penguinist.......I'll give it a go later on today and report back.
Hi Penguinist......at this point I do not know whether to laugh or to cry - I'll try both.......The location of the config file is quite correct - I checked on the web and it should be in .config......but of course, it isn't. VLC has never started and therefore it has never created its config file........and so, I can take no further action down that path.

Y'know.........I could quite easily throw this whole openSUSE 13.1 into the trash can and try Linux Mint for the first time. I shall meditate on it. But this is getting to the ridiculous stage. VLC and Xine both run perfectly in openSUSE 11.4 in 32bit mode on that 64bit laptop.........Perhaps the other alternative is to "bite the bullet" and run the older OS.....but I am reluctant, even though it works perfectly on this older 32bit computer on which I am . One feels one is wasting available computing power. Whoever said computers save time ? On the other hand, they do provide rather nice puzzles for you to work out.

> Actually Ridcully is probably not running vlc as root, so his configuration is probably in

Duh. Correct.

> but of course, it isn't. VLC has never started and therefore it has never created its config file

Sigh. Oh well, it was worth checking. I wonder what vlc gets it's initial config from?

The only thing I can think of that might still be worth trying is running strace vlc from the command line. That might show what's causing the segfault.
I am not certain yet, but the problem appears to be conflicts of where you get the packages from and also a major conflict with libdvdcss..........My latest attempt to get a working installation of VLC is that I have installed VLC using openSUSE's repository and it will open, and does NOT instantly crash and disppear "off the workplace" when you ask it to run a dvd......Then, when you introduce a copy of libdvdcss, it does exactly that........libdvdcss2 has not so far proven to be acceptable. I am looking at some files which deal with KDE-codecs, etc. etc and given that this is KDE based, it may solve the problem.

This problem of software conflicts is (in my humble opinion) largely due to the fact that openSUSE will NOT package a working copy of VLC plus libdvdcss in its distribution, due to USA laws, but at least I think I am beginning to narrow the field down.......Wait for the next exciting episode of............wait for it, wait for it......... VLC and openSUSE 13.1.....LOL.
Hmm, I thought VLC included it's own version of libdvdcss. I know the Windows version can read DVD's and Windows doesn't have anything equivalent to libdvdcss. This sounds like something that needs research.
It's normal to receive the following message running vlc from command line from a KDE konsole:

main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.


I think you're probably on the right track about it being a problem that openSuSE doesn't package vlc with it's main distro. You might want to try obtaining an SRPM and building your own RPM package from that... Either that or use a "civilized" distribution,... ;)
> I am not certain yet, but the problem appears to be conflicts of where you get the packages from and also a major conflict with libdvdcss.

Are you using this guide?: http://opensuse-guide.org/codecs.php This one also has more information: http://www.dedoimedo.com/computers/opensuse-pimp.html
For jdixon.......Quote: I know the Windows version can read DVD's and Windows doesn't have anything equivalent to libdvdcss.

Interestingly, I believe the opposite.......I know I had to search and find at one stage, a file called "libdvdcss-2.dll" while playing with VLC on a Win7 computer. Once installed in the appropriate directory, VLC ran, but there was NO way it would run without that .dll file, and it's still on this Linux computer in an archive file.

Whaddya mean "civilized" distribution, JaseP......? This means war. I demand a duel: loaded bananas at 20 paces. However, seriously, I have "flirted" with the idea as well....What do you use or would recommend ? I have never used a distribution based on ".deb" and all my files and backups of software are all ".rpm" based.
BTW:

To check if libdvdcss is installed correctly with a searchable path:

$sudo ldconfig -p |grep libdvdcss

EDIT:

Oh yeah... you'll be able to see what libraries vlc is linked with by:

$ldd /usr/bin/vlc

> Interestingly, I believe the opposite

I looked last night and found that I didn't have VLC installed on my current Windows 7 machine (which just goes to show how little I use it). I installed it and confirmed I could watch my Serenity DVD with no additional software installed. So I'm not sure why you had to install additional software.

The VLC directory on my Windows machine contains a folder access which contains the libdvdread and libdvdnav libraries. So I can't say for certain if vlc has it built in on Linux or not. So time for that research...

OK, from the VLC FAQ

I cannot read DVDs! ... If you are on Linux/Unix, did you install the '''''libdvdcss''''' package?

So yes, the Linux version of vlc requires libdvdcss. The howto's I linked to above give a procedure for installing it. Maybe you're using the wrong version?

Email Client Choice

The first GNU/Linux distro I tried was Gnome based, and so I had always used Evolution. At some point I became frustrated with Evolution and went in search of a fast and more transparent email client. This search ended at 'sylpheed':

http://sylpheed.sraoss.jp/en/

Just like you, I was unfamiliar with the general ideas behind and between maildir and mbox. And just like you, I discovered that mbox is the 'universal' export/import-able format. It just happens that sylpheed uses the mbox format directly, so this made the export/import tasks less complex.

In any case, I have about 15 different email accounts that I monitor throughout the day... Evolution was very slow in checking each and my system would sometimes strain if a given folder had many messages. I have no such problems with sylpheed. However, what I do have now is a problem with integrated calendars...

Without the Evolution or Kmail calendar function I have searched, without much success, for an acceptable stand-alone calendar...

BTW:

Quoting:The first is to use the "mbox" export method and keep that set of files as an "unreadable but savable" copy.


mbox is definitely readable. In fact, it's plain text... that's why the import function is so fast. The documentation in sylpheed contains a justification for the use of mbox due to speed considerations. So, if you have an old computer, it may be a good idea to use an email client which stores local email in mbox -- the speed of storage, retrieval, and search is much faster than maildir or the various DB methods.

As a side note: I really am unsure why 'heavy' email client developers are so enthralled with sorting all data through a single metadata 'engine'. It makes everything more difficult to unravel when workflows need to be adjusted.
mbox versus maildir:

http://serverfault.com/questions/564456/maildir-vs-mbox-what... http://www.linuxmail.info/mbox-maildir-mail-storage-formats/

Most people consider maildir to be a better format, and as far as technical reasons go, I'd have to agree. That said, unless I'm dealing with extremely large mail files, mbox seems to work fine for me, and it's the default for the mail clients I use .
I note the quote dotmatrix. The reason I wrote that text was that when I selected one of those mbox files, the result was that a "first in line" message popped up with an additional bit of info which said that "the mbox file contained lots of these messages but only the first could be presented".........so I assumed that the file as a whole was not directly readable. Thanks for the comment though.
Well... I have corrections to make to my claims.

Sylpheed does not use mbox. It does export and import mbox. However, the storage of local mail is one plain text file per message... similar to maildir.

My basic point was:

The 'heavy' email clients all seem to be rather slow and resource intensive, especially considering that most of email is plain text with no attachments.

sylpheed is very fast. I think 'Claws' is a 'heavier' version, and may include a calendar -- it's been awhile since I've looked.

I think it's important to remember that a 'preferred' application may not be appropriate for lower spec machines. And I would usually recommend sylpheed or claws on an older platform.

EDIT: to include simultaneous above post...

>so I assumed that the file as a whole was not directly readable.

Since I had to export everything to mbox... all my old emails are stored in mbox...

I've found this very convenient because I can use 'grep' to quickly find anything I want -- all the way back to emails from the '90s -- in just a few seconds.

However, I still am unsure why there seems to be a dearth of high quality stand alone calendar applications... one that uses caldav and does not use Google or assume that the end user has a gmail account... and other yada, yadas ...
from my experience the advantages for mbox are:

* less diskspace, especially if you have lot's of small files.

* much faster to open and read by the mail client, as only one file needs to be opened

the downsides are:

* easier to corrupt. more likely to happen if you have multiple applications accessing the mbox file. (like maildelivery to mbox and your mailclient updating the mail status. i once lost a years worth of emails because of that)

* need to be reindexed every time mails are updated, because offsets change. again more likely to happen if accessed by multiple applications at the same time.

i am still using mbox on my inbox, but since i switched from mutt to sup, i no longer get the speed advantage because sup keeps a separate full-text index, it also doesn't like it at all when another process (like imap) messes up the offsets it has stored.

greetings, eMBee.

greetings, eMBee.

Dare I start a third thread?

I haven't really ever used KDE. I generally don't like Qt applications, and have never really enjoyed the look and feel of KDE. So I have avoided KDE and Qt as much as possible.

Well... after reading the story, I had a look at Akonadi. I gotta say, it looks scary. The systemd folks over at Red Hat are behind the times when it comes to gobbling up everything. It looks like Akonadi got there first...

Here's someone's blog post about Akonadi:

http://www.dvratil.cz/2016/01/kde-pim-still-alive-and-rocking/

It's funny how much it parallels the systemd folks. It's definitely all about uniformity, conformity, and "my binary data stove pipe is better than yours" ... whatever happened to flat plain text files?

/end mini-rant

I'm feeling a common thread here with KDE, systemd, Android, iOS, Windows, Chrome....

It's all about asserting control.

He who gains control of the most users wins.

With closed proprietary software the battle is already won (or lost depending on your perspective) since those users have never had an expectation of controlling their own systems.

The battle for control inside a Linux environment is a bit more difficult to win. Google does it by combining closed/secret software along with their open kernel, and by using vendor configured selinux to lock systems even to root users. KDE and systemd gain control by "gobbling", moving configurations to binary formats, and by cloaking secrets through complexity. What users don't see, they don't control.
>What users don't see, they don't control.

Yeah -- I agree that seems to be the main objective. For myself, I like to know how everything works. I greatly dislike 'hidden' complexity. Unfortunately, many younger developers seem to be under the false impression that choice is bad and so try to hide the 'difficult' configuration items from users. I tend to think this is not the correct direction. What's the harm in leaving all the configuration items on the list and having an 'advanced' tab to reveal the less common choices?

But, then again, I'm just a lowly end-user for the most part... and like the current US political primaries... who cares about the end-user, 'we' don't need them, and they don't know what's good for them...
Take a look at my comments on the thread "Untitled"..........

http://lxer.com/module/forums/t/36176/

I agree with the KDE thing. It feels very cartoony. If Disney made desktops it would look like this. Even the supposedly world beating Plasma feels clunky.

I like GNOME as a desktop environment but it also has to be said you can't really beat a well configured XFCE or LXDE.
You know, I have noticed that Qt doesn't necessarily look exactly like KDE apps or pull in as much overhead. When I install Kid3-Qt instead of the regular KDE version of the application, it pulls in fewer dependencies and looks much better on a non-KDE system. Also, I have a live Linux USB stick with an LXQT desktop, and I don't have a problem with it, while KDE tends to be too heavy for me to really like it.

Untitled

At one time Kontact 4.x could just take mail copied into the location. In fact, I had a script that would back up and restore my mail since I was having so much problem with Kmail losing it at the time. I don't know exactly when it changed, but at some point I could not do that anymore. There really needs to be an option to not have AKonadi to use Kontact/Kmail. I mean it is so pretty and could be comparable to Outlook otherwise....I finally just switched to Thunderbird and within a month of doing so read that Mozilla is trying to dump that project on another foundation. I think what I would like is a good fork of Kmail 3 that works on qt 5.....
I'd have to more or less agree. KMail as it was originally developed was an excellent, stand-alone program. The KDE and KMail teams have made it totally dependent on the operation of another piece of software, Akonadi. As I proved in my articles, if Akonadi is not present and running, KMail will not function. Further, the absolute dependence of both KMail and other parts of KDE on Akonadi has now become what I would call "obscene" from a software viewpoint. There are probably some users who want this "non-choice-integration" of Akonadi, but equally in a FOSS world, there are others who neither want it nor need it.

The removal of user choice is one of the worst possible charges you can lay against FOSS developers, but I personally would definitely make it against the KDE/KMail developers. There should have been a way for Akonadi to be available if required, but only operating if the user wished; this would have left KMail and the rest of the components of the Personal Information Management suite free to operate independently at the user's desire. Perhaps it was just too hard or time consuming for the KDE/KMail team to undertake such a development path, so they chose the easier way to force every body onto the simpler path they wanted - because I think it would take real developmental effort to retain the "use or not use" choice of Akonadi. But who knows ?

I've also made an oblique reference to another aspect of KDE/KMail/Akonadi with respect to speed. In my opinion, if you don't have a 4-core 64bit computer, my advice is not to even consider KDE/KMail/Akonadi......an older 32 bit computer simply cannot handle the software fast enough.
> if Akonadi is not present and running, KMail will not function.

This seems to be because nearly all of the communication with email servers and storage and retrieval has been offloaded to Akonadi.

If you look at the Akonadi website:

https://community.kde.org/KDE_PIM/Akonadi

it's apparent that Akonadi is not so much of a 'dependency' of KMail... it's actually more than half the application. So, it's impossible to remove Akonadi from KMail... That would be like trying to boot an OS without a kernel.

And if you want a real eye opener, read the PDF report about the goals of Akonadi:

https://community.kde.org/images.community/e/ee/Robert_Zwerus_-_Storing_PIM_data.pdf

***

>an older 32 bit computer simply cannot handle the software fast enough.

I'm sure there are many other opinions, but it would seem that the latest KMail would not be a good choice for an older machine.

Again, I would recommend sylpheed for older machines.

Here is some realtime info from my machine:

PID   USER    PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND 
20170 xyzjkl  20   0  520.0m  41.9m  24.6m S   0.0  0.2   0:06.75 sylpheed
I am displaying 12 open IMAP mailboxes each containing about 3000 messages. As well as a local archive containing more than 10,000 messages.

As you can see my many open mailboxes, messages, and connections only use about 65MB of RAM and since I've had the email client open for about 12 hours, you can see it doesn't use many CPU cycles either.

sylpheed is awesome... as long as you like your email in plain text [no html, but does include images], which is a good security practice anyway.
Oh yes, dotmatrix, I found out just what the KDE developers had done by doing the experiment of deleting Akonadi from KDE.......You end up with KDE totally unusable and as all the software that is dependent upon Akonadi is also deleted, you sit back in horror as you realise what these foolish, foolish people have done. I concluded that Xfce was probably the better window manager at this stage and it would be wise to move to another email client. I documented all of that in one of my three articles.

It was purely my "bl...dy-minded" stubbornness that made me make the attempt to get those emails into the latest version of KMail and I succeeded; but it doesn't make me any the happier with the overall development of KDE which now has become a grotesque caricature of the elegant software it once was. This is being written on openSUSE 11.4, the last version of that software that still had a version of KDE that retained most of its elegance and simplicity.

Now that I have achieved my goals with that latest version of KMail, I will probably wipe the whole drive and see if I can find an archival copy of openSUSE 11.4 in 64 bit mode. Then experiment with that.....AS I remarked in my articles, the KDE/KMail team don't give a tinker's curse about the users, as long as they have done what they want to do. But one of my conclusions in my articles was that I could not recommend KDE in its current form to any beginner in Linux because of its Akonadi monolith......I am still of that opinion. I think it may be time for me to get very serious about openSUSE 13.1 running Xfce.

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:
|||||
10
Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help

Sign up and post (it is free)  or  Log in and post

LXer

  Latest Features
bob: LXer now speaks Markdown
Oct 27, 2026

bob: How to protect against PHP2Shell
Oct 26, 2026

Scott Ruecker (San Diego, U.S.): Linux That's Small
Oct 14, 2024

penguinist: Encryption, Trust, and the Hidden Dangers of Vendor-Controlled Data
Aug 27, 2024

Scott Ruecker (San Diego, U.S.): My Linux Mint Tribute
Aug 23, 2024

Scott Ruecker (San Diego, U.S.): How I Turned My Chromebook Into A "Mintbook"
Jul 08, 2024

Scott Ruecker (San Diego, U.S.): Adventures With My New Chromebook
Jun 10, 2024

Scott Ruecker: My Linux Laptop
May 08, 2022

Scott Ruecker: Laptop Dual Boot Project: Part 2
Nov 30, 2021

Scott Ruecker: Laptop Dual Boot Project
Nov 30, 2020


View all

  Search Features

Search LXer Features:

[ Copyright © LXer | All times are recorded in Central Daylight Time (CDT) ]

[ Contact Us | Privacy Policy | Terms of Service | About us | rss | Mobile ]

Login