The KDE community is happy to announce another update for the KDE 3 branch. KDE 3.5.9 is the latest bugfix and translation update for those who cannot or do not want to switch to KDE 4 yet. While currently no subsequent release for KDE 3 is planned, we will make sure to provide updates as they are needed to run your KDE3 smoothly also in the future.

The KDE-PIM enterprise branch that has enhanced functionality and stability in the PIM components KMail, KOrganizer, KAddressbook, KAlarm and of course its shell Kontact is merged back as official part into the KDE3 branch. Techbase has details about the changes in KDE-PIM. Among those are:

A Favourite email folders view in KMail, as well as drag and drop
support for folders

Easier scheduling in KOrganizer through various improvements in the
user interface

Is the changelog actually complete? I was expecting some fixes to kdelibs/kdebase. 3.5.8 introduced a rather subtle but annoying bug in Konqueror I was hoping this release would fix. No biggie anyway, I'll install it and cross my fingers.

No, the ChangeLog is not complete at all. It is written by hand (well, in a XML file, the PHP/HTML is autogenerated from the XML). Most developers do not update the XML after each commit. There are many many more changes between 3.5.8 and 3.5.9.

It would be nice for these maintenance updates to be able to see what changes went into them. If the devs don't have time to update the list, perhaps just a link to all commits between 3.5.8 and 3.5.9 would be an alternative? I assume this would be fairly simple to get..

I've had several problems with the enterprise patches, and the biggest is that sending mail doesn't work. It doesn't print any error messages anywhere, and when I installed "plain" KMail instead, the messages got sent right away.

I'm just wondering if it wouldn't be better to have a monolitic Kontact instead of using different small applications. I find it weird to have different dock icons for each sub-application. Couldn't it be possible to integrate everything into one single app ? Moreover, having so many configuration dialogs is hard to manage.

I know that this architecture provides the ability to only use the sub-components alone if needed, but for those who are looking for a professional centralized application (Outlook-like to be rude), it can be disturbing.

Talking totally about something else, is it planned to integrate the Google Apps APIs into KDE-PIM ? It would be nice to support GCalendar out of the box for instance.

Wouldn't it be better to concentrate on improving the integration between the components within Kontact where needed? Surely this would be a lot less work than trying to roll all of the components into one huge monolithic application.

Other than the configuration dialogs, where would you like to see more integration between the components?

To be honest... I don't really know. Everytime I tried to launch Kontact, I got the KOrganizer and the... what was it again... the RSS aggregator... icons in the dock. Then I tried to configure the KMail part to get my GMail account through IMAP, and never found the option to root into a subdirectory (which is [Gmail] in the case of GMail)... Then gave up... Too many icons in the dock + blurry config + no easy GCalendar integration, I decided that Thunderbird + Lightning + GCalendar plugin was better suited to my needs, even if it doesn't integrate that well into my KDE.

So I must say that I can't really be of great help. I was just suggesting a usability goal, based on the fact that I personally got lost because it didn't feel... erm... united enough. I would just say that a single tray icon, and stripped down unified config dialog with advanced options being just one click away would be great. Easy to use at first try, easy to tweak afterwards.

If the icons annoy you ( they did annoy me as well) each application has an option to remove the icon from the tray. Voila you are left with no icon or the icon of kmail/korganizer/... or whatever icon you find most helpfull. This is actually a great way to customize the way the application presents itself to you. You need of course to go through the config dialogs for these applications but these are very well organized and you will find your way through if you are willing to spend a few minutes.

which is why the system tray just... well.. sucks. it's an old concept and it's not working any more.
what we *really* need in this case is a kontact plasmoid. I'm sure it's just a matter of time before one shows up; akonadi should make stuff like that extra-easy :)

The difference between plasma and the systray is that the systray is always visible and docked into a panel with other "always on top" things. I don't want to access the plasma dashboard in order to click the icon. It should just be one click away, with no need to use the keyboard (I know, that's the current trend : use the keyboard more... just look at the new kmenu replacements. But I am lazy, and I don't like hitting my keyboard while I could just use my mouse. I spend most of my time just using a mouse, with my left hand holding a pen and taking notes. And that's the way I like it, I don't want to be forced to use both of my hands... Erm... sorry for the digression :) )

I guess that the systray is not dead and plasma is not the perfect solution to every problem (even if it is an amazing piece of work).

"The difference between plasma and the systray is that the systray is always visible and docked into a panel with other "always on top" things"

Er ... you do know that the systray is actually a Plasmoid, don't you? There is absolutely no difference between a Plasmoid and something that can be "always visible and docked into a panel with other 'always on top' things".

"I don't want to access the plasma dashboard in order to click the icon."

You won't have to - just dock it in a Panel where you can always see it.

I was thinking long and hard today along similar lines. KDE should form a strategic partnership with Google in much the same way Mozilla did.

As far as the API goes, you only get so many uses for your API key, so KDE couldn't just take the API and use it without paying for it, or striking a deal. They'd go over API usage with all the people who use KDE.

However, imagine Google contributing code to NEPOMUK and improving Strigi.
Imagine fully integrating Google services like GCalendar, GTalk and Gmail into your desktop.
Imagine easily integrating Google Docs to share documents.
Imagine being able to search an index with your account, and have it know that what you're looking for is on another computer you've used recently.

KDE 4 is now cross-platform. With plasmoids, open APIs, and the beginning of the Semantic Desktop, you could fully integrate your desktop experience with an online community, and simultaneously integrate online services into your desktop.

The partnership would profit both parties, and the end users would get much better features.

You could take it even further. It could create in-roads for KDE usage in the Enterprise environment through the strength of the Google brand. I can tell you first hand that integrating Sharepoint is very costly. Imagine an OSS alternative that allows the entire enterprise to communicate via email, calendar, IM, share documents, collaborate, search, etc. intuitively, and directly through your desktop apps.

We need to brainstorm this, and someone needs to approach Google about this.

you got a point, but so does he. Working with Google has advantages and disadvantages - we can use money, resources and goodwill, but we don't want to be tied into them, offer google as only option. Luckily, it doesn't have to be that way - see the Magnatune integration in Amarok - it's now pluginbased - in part thanks to Magnatune contributions! Some companies really *get* FOSS, are genuine and willing to properly contribute to and work with us. Google has been doing well, so I think we could/should work a bit more - but not commit to ONLY google.

Indeed, Magnatune paying an Amarok developer and even letting him implement support for competing music stores is very nice of them. Cooperations like this (with no lock-in involved) are beneficial to KDE.

> I'm the one to thank if you ever use Kompare in KDE 4, I got it from non-building to shippable in KDE 4.0.0

Thank you for giving Kompare some attention. It semmd to be abandoned for so long! Like I was the only person left using it. And I use it a lot, mostly to review my own changes before committing to SVN (svn diff|kompare -&) and of course configuration file changes on Gentoo (set pager="kompare -" in /etc/etc-update.conf). Did you just port it or did you also fix some of the old bugs? 2 of the most annoying are that it does not understand directory structures (output of "diff -r", see [http://bugs.kde.org/show_bug.cgi?id=139233]) and that pressing "Next file" jumps to a random file, not the next in the file list.

Our technology by and large directly competes with Google. Trolltech/Nokia compete with the GPhone, KOffice is a competing Office suite, Strigi does the same thing as Google Desktop etc.

Google does help us out (KDE 4 release event, tons of students for Google Summer of Code) I think mostly because creating a non-Microsoft software ecosystem is ultimately in their interest. And because we're cool. :)

Trolltech/Nokia does offering a competing product against Android, but that doesn't mean that Google would never partner with KDE. Google doesn't offer an offline Office suite, so there is zero competition there. Google does support ODF, just like KOffice, and Google would suddenly provide a means to easily share your documents online, and to allow collaboration. And I didn't think Google offered Desktop Search on Linux or Mac.

Who knows? With a partnership, Strigi could effectively become the new Google Desktop search, except it would be FOSS, and it would strengthen the KDE brand.

I don't know about the rest of the world, but in corporate America, FOSS is a dirty word, where as Google is highly respected. Such partnerships would increase visibility not only to individual desktop users, but also to enterprise environments.

If Google had something against Strigi, KDE, KOffice, etc. would they spend money out of pocket sponsoring Summer of Code projects for them?

As you already stated, they like to promote a non-Microsoft software environment, and they seem to respect KDE. In much the same way they assist MySQL and Mozilla, I think Google could help KDE.

I do worry about Google, simply because it has become so large and expansive. That said, I do use Google's calendar (since it is the only way I can keep my workstation, laptop and Blackberry in sync) and GMail (which has a very annoying "feature" where you can only download mail once via POP).

The GCal/kitchensync plug-in is broken (dies if you have recurring appointments, and who among us doesn't have weekly/monthly meeting scheduled as such) so it is a pain to sync w/ KDE Calendar (which is much more functional, at least this week).

I do think, however, that collaboration with Google _and_ Yahoo! is in everyone's interest.

Also, having a Blackberry sync mechanism for KDE PIM should be a super high priority. I suspect there are a lot more Blackberry users out there with similar problems.

>new enterprise PIM? So bascally everything that has been avaible with opensuse for a few months, it's not really new then is it

Not exactly the same. opensuse just shipped a several months old SVN snapshot, from a time were the enterprise branch still was very much in development.
3.5.9 has a feature-complete and more stable PIM than the old suse packages (and the same is true for the other distributions).

Additionally, the enterprise branch didn't have any translations (except German), while 3.5.9 has all the usual translations.

Fedora's snapshots got updated regularly. Moreover, we kept the original kde-i18n translations, so there were just a few untranslated messages for the strings added on the branch. But we have kdepim (and kde-i18n) 3.5.9 (plus 2 KMail bugfixes which didn't make the tagging cut) in updates-testing now, and will have it soon in updates, for both Fedora 7 and 8.

I just upgraded my Kubuntu boxes last week and got KDE 3.5.8, which gave me at least two regressions -- a major kded bug (CPU-eater, though it seems to have bitten some people in earlier versions) and a minor (but damn annoying) konqueror bug (load-plugins-only-on-demand not working). Yes as I recall both of these are in the bug database.

Speaking of KDE-PIM. These days, living in an Uni environment where most clubs, societies, and friends have their own facebook page and use it to schedule events, it would be really nice to have some Facebook integration in Kontact.

I've heard about some akonadi facebook integration. Are those the first steps in that direction?

Would be really cool, but not only for facebook, also other social networks. Also an exportoption for Kadressbook to only export emailadresses for uploading them and searching for friends in social networks.

That would be great actually. Also goes for other online messaging systems (e.g. forums/messageboards Inboxes). It's crazy generating extra "email" when it could be managed as like an (IMAPish) folder.

Might be easier if a spec can be drawn up to manage this sort of stuff? Then sites/systems like this can expose some nice and simple APIs rather than rely on HTML parsing from the normal site's output.

I've looked around and found that:
- there are no external APIs in phpbb
- facebook API (notifications) is pretty simple XML affair
- I could probably to construct a similar APIs in WordPress(easy) & Phpbb (it's been a while)

So the 'hard bit' would be writing the code from within KDE - especially given I've not written a KDE app before. Does anyone with relevant Kontact/Kmail plugin experience have any words of wisdom about how to go about this?

What's the current situation with the changeover to KDE4/new systems for data integration etc.?

Yes, there's a kfacebook library in playground/pim and the start of an akonadi contacts resource there.

However the Facebook apis are very limited - you can't create new events or edit anything, just view what is there. The last time I looked, even changing your status message was not possible. I'm more optimistic about the OpenSocial APIs.