Language Selection

English French German Italian Portuguese Spanish

KDE 4.4 Mail Misunderstanding Explained & Akregator Surprize

Filed under
Linux

I've gotten quite a few responses to my quickie look at KDE 4.4 under Mandriva written for this week's Distrowatch Weekly. One of which came from Aaron J. Seigo himself. I thought I might share some of what he said since several people expressed similar concerns on the topic here in comments. I also found one really super-duper neato new feature in Akegator in 4.4 that deserves a mention.

First to all, that wasn't meant to be a thorough review of KDE 4.4. I just wanted to talk about how easy it was to upgrade Mandriva and to install the KDE 4.4 packages and perhaps mention a few observations.

But one concern that several people besides myself have mentioned about KDE 4.4 PIM here on Tuxmachines was our understanding that our emails used in KDE PIM will be converted from our maildir format to database entries. This would make testing various distributions a bit more difficult. I know a little MySQL, but I really didn't want to be dumping and restoring a database every time I changed distributions.

But Seigo explains that our mail will not be converted and stored in a database. An index of our mail will be made and stored in a database table so that other applications could make use of it. Apparently, allowing for opening and accessing the mail in its current directory and format if need be - for example, as in a plasma widget on desktop monitoring for new mails. At least that's how I understood his explanation.

Well, instead of interpreting, I'm sure it would be alright to just post his exact words:

Actually, Akonadi doesn't change storage format (that wouldn't be a good move, really) but it centralizes access to the storage as well as provides uniform indexing. Right now, indexing systems aren't shared between mail/calendar/contact systems anyways, and Nepomuk allows the indexing to be shared between all desktop apps that use it. Akonadi itself provides access to the mails on disk so that it's safe for both, say, KMail and and a Plasma widget to be displaying the contents of the at the same time. So instead of being a heavy or "lock-in" style database, it's simply an access mechanism to storage formats that you and I are already (and will continue to) use.

I know this takes a load off my mind as I hope it does the others who expressed concern as well.

---

Now for the super-duper neato new feature in Akregator:

Akregator used to display polls and such as plain text, but with 4.3.2 polls rendered in radio-button or clickable format. That was kinda nice. But today I discovered something even better.

For Webmasters/bloggers/whoever that allow such, videos can now be watched right from Akregator. I don't know any real details, if only certain formats are supported and such, but I'm almost thinking they'd have to be oggs. I'm not sure if Flash videos would work as I disable all such in Konqueror/KDE. I'll check next time I see where someone embeds one in a feed.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: akonadi problems

On my experimental box, I'm running Mandriva's development version called Cooker (currently in Alpha state). When Cooker KDE packages were updated to KDE 4.40, akonadi wouldn't load, so kmail would terminate. Irritating. Started looking on the net, and in logs. Turned out the akonadi MySQL database config was incompatible with the MySQL packages in Cooker.

Some small changes in the akonadi mysql config file got it working.

Oh well, such is the life with alpha stuff.

Wish KDE would allow kmail to run without akonadi, for the time being.

re: akonadi problems

oh no. Another issue to be wary of. That won't be the only occurrence of similar in the coming months I'm afraid.

Yes, there should be some choice in the matter. A lot of folks would rather not have to have a database installed on their desktop.

Issues of space, resources, unknown future of mysql... that database indexing should be an option one can opt out of.

More in Tux Machines

BeagleBone Announces the Open Source PocketBeagle USB-Key-Fob SBC

  • BeagleBone Announces the Open Source PocketBeagle USB-Key-Fob SBC
    You've probably heard of BeagleBones and the Beagleboard Foundation by now (check out that link if you're not familiar with them). They make open source SBCs and have an online community much like the Raspberry Pi Foundation. While Beaglebones don't have as large of a community or market share as Raspberry Pi, their boards are still quite popular because they tend to be more application-focused than Raspberry Pis. For example, there's the general-purpose Beaglebone Black, the sensor-oriented Beaglebone Green, and the Beaglebone Blue for robotics applications.
  • What is PocketBeagle?

today's howtos

Graphics: NVIDIA, Nouveau, X.Org Server

  • NVIDIA Making Progress On Server-Side GLVND: Different Drivers For Different X Screens
    While NVIDIA isn't doing much to help out Nouveau, at least the company is contributing to the open-source Linux graphics ecosystem in other ways. In addition to presenting at XDC2017 this week on the Unix device memory allocator API and DeepColor / HDR support, they also presented on server-side GLVND. Server-side GLVND is separate from the client-side GLVND (OpenGL Vendor Neutral Dispatch Library) that evolved over the past few years and with modern Linux systems is supported both by Mesa and the NVIDIA binary driver. Server-side GLVND can help PRIME laptops and other use-cases like XWayland where potentially dealing with multiple GPU drivers touching X.
  • Nouveau Developers Remain Blocked By NVIDIA From Advancing Open-Source Driver
    Longtime Nouveau contributors Martin Peres and Karol Herbst presented at this week's XDC2017 X.Org conference at the Googleplex in Mountain View. It was a quick talk as they didn't have a whole lot to report on due to their open-source NVIDIA "Nouveau" driver efforts largely being restricted by NVIDIA Corp.
  • X.Org Server 1.20 Expected Around January With New Features
    X.Org Server 1.19 is already almsot one year old and while X.Org is currently well off its six month release cadence, version 1.20 is being figured out for an early 2018 release. Adam Jackson of Red Hat who has been serving as the xorg-server release manager held a quick session on Friday at XDC2017 to figure out what's needed for X.Org Server 1.20. His goal is to see X.Org Server 1.20 released in time for making the Fedora 28 version. For that to happen nicely, he's hoping to see xorg-server 1.20 released in January. The Fedora 28 beta freeze is the middle of March so there is still time for the 1.20 release to slip while making the F28 Linux distribution update.

ASUS Launches Its Thinnest and Lightest Flippable Chromebook, the Flip C101

ASUS announced a new Chromebook on its website, the Flip C101, which is a smaller and lightweight version of the C302 model. Featuring a 10.1-inch touchscreen display, the all-new Chromebook is priced at only $299 in the US. Read more