The KDE PIM community gathered at Osnabrück, Northern Germany for a weekend in February. The discussions covered recent achievements in KDE PIM, the current state of the community and applications, and brainstorming about the future and new cohesive and social applications. The meeting as usual had many attendees and was hosted, as in each of the previous 8 years, by Intevation GmbH. The agenda reflects the breadth and scope of this year's meeting, ranging from website maintenance to release engineering to features and tools.
Entering new ecosystems
Part of the advantage of an annual technically focused meeting is that it brings an opportunity for a retrospective on the year gone by. One of the topics on the agenda was a demonstration of the Kontact Touch application suite. The Kontact Touch initiative was announced as an ambitious plan at the last KDE PIM meeting in Osnabrück; we have been following its development here on the dot and in other technical media outlets. Kontact Touch, primarily suitable for personal handheld devices, was demonstrated on the N900 (MeeGo mobile UX), Lenovo IdeaPad (MeeGo netbook UX), HTC Touch Pro2 (Windows CE), the Aava Mobile Smartphone and the Wepad. The touch-orientated user interface uses much of the same technology and code as the equivalent desktop applications so it is possible to port them to any target where Qt and D-Bus are available.
Fresh ideas
Friday evening, meeting participants had an opporunity to set out an agenda for the rest of the weekend, and to start "community building" (read: dinner and drinks :) ). Dinner for the weekend was sponsored by Intevation, KDAB and Kolab Systems. One of the goals identified at the last Osnabrück meeting was to grow the KDE PIM community. This has been a success in many ways as demonstrated by the fact that some of the new community members attended the meeting.
Christian Mollekopf demonstrated notetaker, a new application under development which combines the notes data available through KJots with TODOs available through KOrganizer. It allows the user a quick area for jotting a note, which can later be converted to a TODO or vice-versa. Christian's application does not depend on KJots or KOrganizer, but instead all three applications access the common data through Akonadi. The application also relies on Nepomuk for tagging, rating and search capabilities. These kinds of applications--combining data in different ways through multiple applications--are likely to be the future direction of innovation in KDE PIM. We spent some time discussing concepts and ideas for how we can combine and (locally) aggregate data in useful ways.
Cornelius Schumacher also demonstrated Polka, an application written during the recent openSUSE hackweek for managing addressbook entries. The most visible innovation in Polka is the arrangements of contacts not in the traditional form of a list or tree, but in free-form and radial arrangements and groupings. The user can group different contacts together using drag and drop depending on context (such as family, university etc) and add notes directly in any way desired. Another nice, modern feature of Polka is version control. Even when data on a contact is changed (such as phone number or email address), it is possible to traverse backwards through history to find the old data. All attendees were excited to think of how we can build innovations like this into existing KDE PIM applications.
Releasing Early Releasing often Releasing
A hot topic for this meeting was of course the release of the KDE PIM 4.6 desktop suite based on Akonadi. All of KDE PIM has seen huge improvements in stability and completeness over the last year. The team identified some remaining hurdles for users and started working on resolving them. This work involved simplifying the data migration during upgrade and updates to various interactions with Nepomuk to resolve performance issues. The end result is that a final KDE PIM release is expected to be made during the 4.6 KDE release cycle. KDE PIM 4.6 will not be part of the spring release of popular GNU/Linux distributions, but will be made available through unstable/backports repositories for early adopters. Part of the discussion centered around PR and framing the release to be aimed at early adopters and technical users.
Community growth
With the new concepts available in the KDE PIM platform for innovative developers, a flexible web presence is essential to help document how to join the community. Modernizing the KDE PIM web presence has been a regular topic since at least 2007, and this year Ingo Klöcker completed the migration from the old http://pim.kde.org/
subdomain to the KDE Community Wiki. The actual content still needs updating in some areas, but organizing the pages into the crowd-sourceable wiki is a major step in creating better content.
The meeting also brought lots of opportunity for API and bug fixing as well as new developments. The weekend saw the development of a Facebook resource for Akonadi, making Facebook data instantly available to all KDE PIM applications. There was lots of discussion around solving persistent problems in PIM, such as handling deleted data, a generic import/export framework, future-proof handling of DAV and Free/Busy information, merging of contacts and 'Person objects' and much more.
As there were many people with many important discussion topics, the meeting participants broke out into several focused groups for special topics. These included:
- Demonstrating a new Kontact on Windows package with improved build system. Ralf Habacker from KDE on Windows was a special guest for this part of the meeting.
- Discussion of invitation compatibility with other applications like Outlook.
- Discussion of speed of sqlite versus mysql databases. The Touch and Windows desktop versions of Kontact are using sqlite sucessfully.
As usual, KDE PIM has entered some ideas for KDE's Google Summer of Code application. Talented students who have some C++/Qt experience and are eager to join the community are encouraged to explore the ideas or come up with new ideas independently. There are plenty of existing developers available to mentor students. New talent is always welcome.
After the meeting is before the meeting
Innovation has long been a focus and a talent of the KDE PIM community. KDE PIM is among the leaders in Qt and KDE, bringing our technology to mobile platforms and touch interfaces. Advances made possible by Akonadi that go beyond speed of access to easy interaction with third party services and new user interface concepts are only starting to be explored. Of course, innovation is not the only focus. Stability and strength in the platform are essential to promote innovation, and work in these areas will remain a focus of the core developers. Growth in the community with fresh ideas and shared infrastructure will help make Free Software the best way to organize people's digital lives. Next year we celebrate 10 years of sustained KDE PIM community meetings - that's more than any other regular KDE community event. There is a bright future ahead.
Comments
Stop drinking and coding otherwise PIM-4.6 won't be released before the revolutionary, re-engineered and groundbreaking KDE-5.0 with Plasma-2.0. The Ballmer's point thing was a joke and doesn't work in practice.
The satisfaction rating with KDE PIM 4.6 is increasing steadily. We do think this will get released.
I'm running KDE-PIM/Akonadi master, and runs here like a dream. You'll certainly like that the IMAP performance is 30000000000x better than KDE-PIM 4.4.
Please, do us a favor and release the stack with the Facebook Akonadi resource, and an update to the Twitter Akonadi resource. The Facebook one is already impressive.
It's close, it's really really close, but we can't afford to stuff up the migration process and lose peoples data, hence the caution.
There's nothing, nothing that scares me as much as losing my email, my mail filter setup or even half a day of getting mail...
Yep, although to be fair, because Akonadi is only a cache it's not the existing emails themselves that are at risk, but configuration, status flags, filters, etc. Send/receive is very stable and has been for a long time. Another big issue was Nepomuk indexing performance, but the latest bug fixes seem to have squashed that problem.
Key will be to communicate properly to users what to expect from the migration, how long it takes, etc.
I had the same concerns, so I thought about doing a backup-copy of my emails using kmail. I connected two email-servers using kmail and proceeded to drag&drop imap-folder from one server into this other. this wreaked havoc and my efforts to backup and migrate my email ended up in data loss and corruption. this was about one year ago, hopefully this problem is now resolved.
As you can see they have almost perfected their "avoid the camera" skill. The first row needs a bit more practice though, maybe next year. ;)
Nice work, looking forward to the next version.
Drats, they caught me pulling my face back to hide all my wrinkles...
So the obvious question is: is there a tentative date? If the (again obvious) answer is, "it's ready when it's ready," I would still like to know whether it is days, weeks, or months.
Cheers, mutlu
We had hoped to have an RC out by now, but there's a few blockers still left so perhaps an RC in a couple more weeks and a final release a few weeks after that if the response is good?
Thanks for the approximate time frame. I know things can change, but having a vague idea is quite nice.
I just hope the next version really includes support to the Ctrl+M functionality. So far even Amarok developers toke that feature back after three years and there seems not to be anymore any famous KDE applications without that feature, even it does not exist at kdelibs so every app would support it.
As for example http://i.imgur.com/DqaeG.jpg
That is now only possible with QtCurve (and Bespin style) what supports experimental function for that. But it really would be great to get it for Oxygen and any other style as well.
Normal users (Senior and junior) does not need manubar at all on daily/weekly/monthly use. They just need a sane defaults to toolbar and they have simply use.
Were there any talks about supporting Ctrl+M?
Indeed. This should be a standard feature in all (KDE) apps.
Trying to pass of the Ctrl+M feature as something for "normal" users is actually quite deceptive, as it's actually a power user feature.
For most applications there are options that "normal" users will need(not necessary daily/weekly/monthly, but occasionally) that will not or should not be placed in the toolbar(to keep the defaults sane).
A normal user will in daily use not "see" the menubar, it's just a stripe of text he/she simply ignore. The user know at some point he/she may need to used the menu. But for daily use it does not confuse, it's just ignored. Removing the menubar kills the ability for "normal" users to find those seldom used, but still required functions. Restoring the menubar is not an option for those users, as Ctrl+M have near zero discover-ability.
As opposed to advanced users, where the magic incantation Ctrl+M is not an hindrance, the removal of the menubar may please the users sense of aesthetic. Such users has the skill to reclaim the menubar when needed, not creating any unsolvable obstacles hindering their use of the application like it would for the unskilled users. Making it a power user feature, rather than something related to usability for simple users.
Morty, you seem to completely misunderstand what is in KDE and what is requested here. Currently, some KDE apps support manually _hiding_ the menu bar by pressing Ctrl-M. Some apps do not have this feature (which comes with KApplication, IIRC). The poster above requested that it get added to KMail, so that s/he can manually hide the menu bar, which is rarely needed and takes up a lot of space on systems with low screen resolution. The feature is there for advanced users, "normal" users will always see the menu bar.
An alternative would be to add a button to show/hide the menu, kind of like in Chromium, although I dislike that it pops up a context-menu-like menu instead of putting the menu under the window title. However, there is not code for such a thing in KDE, so requesting the implementation of Ctrl-M for power users seems like a reasonable thing to do.
It is normal users as well who needs Ctrl+M support.
The only argument not to implent by some developers is that it causes problems when someone by mistakes hides it from settings menu or press Ctrl+M.
But the argument is flawed in the first place.
1. When user press first time Ctrl+M, there comes a pop-up telling that what user had done and how to undone it. There is a tick to not show that pop-up anymore.
2. The shorcut Ctrl+M is not set by default, what means no one can execute it by mistake.
3. The menu hiding function the menu (settings > hide menubar) can be as well be set to be unseen by default and shown later from system settings if Ctrl+M feature would be in kdelibs.
Dolphin, Amarok, digiKam, Konqueror, KTorrent, Kopete, Gwenview, Konsole, Konversation, Okular, K3b, Kwallet, Akregator, KGet, Kate....
The list of Ctrl+M supported KDE applications what even many are in KDE SC is huge... And no problems with mistaken hiding the menubar.
The good UI usability is that when the UI does not have features what are not needed or what can clutter it. Menubar is such if it is not needed in daily/weekly use.
Example in Dolphin, normal basic users does not need menu at all. Same thing with Kopete, Gwenview, Konversation, Okular, K3b and Amarok.
For many very basic users, like juniors (5-10 years old) and seniors (50-80 years old) the menubar is actually very terrible if they do not have already learned the GUI, what most does not have. They only know what to click to get something but are afraid to click something by mistaken, they do not even know what to do with drop-down menus.
That is one reason why Google did design Chrome as such that there is no menubar but just a button for all. As menubar is not needed than in very rare cases and then it is easy to access to it.
Email is a _very basic_ tool for computer. Especially for seniors. There are lots of people who has problems to control mouse well. Hands are shaky or they are just afraid that they click something on screen what they see. It is not just about that they can "forget" them to exist, as they see it and they are afraid of it.
The KDE 3.x series problem was that every option was just thrown to the toolbar and it was soon full of all kind functions what most basic users did not need at all.
At beginning of KDE SC desings, it was ruled that the toolbar should have the daily used functions and else to be moved to menubar. So that users would not need to use menu at all on normal functions. And it has worked very well, basic users gets toolbar with basic functions and they can actually hide the menubar. UI is clear and simple and they can focus just to the tools what they see.
With Ctrl+M support, KDE SC can offer exactly the same clear UI than what GNOME and Apple are trying to offer. But they can offer sametime a powerfull way for everyone to customize the UI exactly how user wants or needs it, without anyone saying "no, you can not do that". And missing a Ctrl+M feature is exactly that every developer is saying "well, you are a senior and even that you dont use advanced functions in menubar, you need to see it and fear that you dont in mistake click menu open when you try to click the toolbar".
Example with the KMail what does not support Ctrl+M feature.
For senior/junior users, they dont have any reason to have menubar shown.
All what they need, is to have a way to receive email and write new one. Reply, forward the one or delete it. And when writing, attach a file to it, as attachment or inline.
Those are the basic functions what most people need in daily/weekly/monthly basis. They do not need any spam wizards, different view settings, configure accounts or similar things.
Most people wants just very basic and easy emailing where they can just sit down on the computer, check the emails what they have got, read them and then answer to them or write a new one with photos or other attachments.
Menubar for most people is not needed at all.
I a lot with seniors and juniors. I setup to them a home computers. I work with people who has disabilities and learning problems. Some people does not remember what they learned earlier. Many people does not even care about computers, all what they want, is to get work done on the computer and then continue to other daily tasks in their lifes.
Having just even the possibility to hide the menubar with any theme (nost just specific themes) on most used applications would be very important. Best thing to happend is that _all_ KDE applications would work same manner. That they would allow actually customizing the GUI to be exactly such what the user needs and wants. Remove all un-needed/wanted features and make the GUI easy as possible to use so the user experience would be only positive.
One GUI does not work for all of the people. Currently KMail (Kontact apps) are designed by default for about 20-40 years old people who are oriented to technology. Not for basic users who do not care about technology or possibilities, they just want to write and read email.
Here is the default setup of KMail for basic users what I setup. They do not need anything else. And if (if!) there comes technological questions/problems, they call to support / helpdesk and usually they dont at all.
http://i.imgur.com/hlG6R.png
And this is the current way how it is only possible without Ctrl+M support (if would be using a beautiful Oxygen style by those who likes it)
http://i.imgur.com/Or2J5.png
Is it clear what difference it is on the UI? Even that tech-oriented person can just pass the menubar, for basic users it is always there.
Some rare setups could be done like this if there would be change to have some menubuttons always at right side of the toolbar: http://i.imgur.com/w62Bx.png or http://i.imgur.com/Tq0Mv.png
That would be for specific people who wants to write like typical letters where you did not add subject in to envelope but you just wrote receiver name and the letter and thats it.
The question was not to remove menubar, it was not to add anything like Google Chrome or MS Office has. It was just very simply question would it be possible to add a very usual KDE application feature to Kontact applications (Kmail and others) to help basic users to get a cleaner and simpler UI.
The code (Ctrl+M) is out there. It is very widely used. It should not be hard to add it and make some default settings.
1. No default shortcut (Ctrl+M) for it
2. Show pop-up notification if menu is hided at first time at KDE SC.
And if being a really well done extra, it would be tried to get to kdelibs where it would be available for every KDE applications.
And then adding a defaults:
1. No default global shortcut for Ctrl+M
2. No Ctrl+M function menu if not enabled first from system settings.
At that point, if someone goes to assing a shortcut and enables the Ctrl+M function and then gets it hided and does not know how to get it back, they can only blame themselves.
And as a just for showcase, here is typical setup for normal users when they use libreoffice writer
http://i.imgur.com/y0C8C.png
They simply dont need anything else.
And even that libreoffice does not support Ctrl+M (or anything like it officially) it is possible to get with a macro.
Or were those KMail UI's too complicated or limited to be used in kindergarten, retirement home, schools or homes for most users? Even that I am a advanced user, I dont use KMail menu at all. What functions do you people actually use from KMail menus every day / week so it is so important to have menubar visible, even if it is 99.9% times just sitting there useless?
Spoiled brats, that's what you all are ;-)
You have fully configurable toolbars and shortcuts as well as a powerful file dialog, bugreporting and language change tool in EVERY KDE app. Happy? Nah, we want to be able to hide the bloody menu ;-)
/me just comes from testing XFCE where all the above goodies are missing...
Hehe. You are of course right, Jos. KDE is awesome in this respect. But then, "elegance" is about many things, one of them would be that such a useful feature would be consistently available across the KDE SC applications.
Something that is very unfortunate is that the zooming options that are very common in other KDE applications, ctrl-+ and ctrl--, are used for other purposes. Even more unfortunate is that there seems to be no general zoom at all.
Is this fixed in the new series?