QML Calendar – KOrganizer replacement – The status thus far.
By now you probably know that i’m that “idiot” that tries to re-create KOrganizer in QML. You might wonder: “Why isn’t it done yet? You’re working on it for about a year now, right?”
Fair questions, but the answer is difficult.
About a year ago i had a working application, it just looked horrible and was made in a hacking fashion because it wasn’t at all certain if the needed data could be exposed from Anokadi to QML. No one really had done that before + the fact that QML was (and still is) very new made it extremely difficult to make something at all. I had to figure things out on my own in the QML world, asking questions was possible but not many people would be able to answer simply because i was playing in an area where knowledge is very sparse and there where just not many people into QML yet. So i wasn’t going anywhere fast and certainly not in an acceptable manner, code wise.
Then came the PIM sprint sprint, early 2013. My initial plan was to have the calendar working and released by that time. As just said, things where going nowhere so we had to come up with “some” grand plan to make calendar data from Akonadi usable for people in QML. The Akonadi structure was close to complete with the “calendaring” branch. During that PIM sprint we decided on a QML API for accessing PIM data. I had a lot of great help wrapping my mind around some odd proxy wrapping stuff to fetch the actual required data from Akonadi. By now that is known as “QML Calendar Components” and can be found here .
That PIM sprint was vital! I now had an easy way to fetch the data i want to have from Akonadi. Even though this is far from finished. Right now it still lacks:
– Todo events (easy to implement)
– Journal events (easy to implement)
– Update existing events through QML (started implementing it, editing some values is already possible)
– Create new events through QML (not implemented yet)
In fact, the components as they are there  right now is how Heena Mahour used them during the last GSoC. And quite successful i might say! She has rewritten the clock popup applet (the popup you see when you click the KDE clock) in QML using those components.
The fact that Heena was successful at creating that using “my” components means that a graphical KOrganizer replacement can now finally be written, or not?! As in representing the data, it’s a definitive yes! However, manipulating the data or adding new entries still remains a big hurdle left to tackle.
Then we still have QtQuick itself. When i made my first proof of concept – over a year ago – i could very easily conclude that QtQuick itself just wasn’t ready to draw the complicated features that a calendar needs. In this area things didn’t improve much. I will still have to do massive hacking to show an event in a ListView. However, things did improve greatly! It’s now very easy (without wrapper/glue) code to change your mouse pointer (resize handles come to mind) and to make proper use of the available space using the new QtQuick Layout components that are in Qt since 5.1. But that is it as well, it will be “less hacky” then a year ago, but still very hacky. I can’t really blame Qt for that. A calendar is an odd beast with non common elements. Don’t even bother asking about events that spawn multiple days. It’s extremely tricky to display that in a week view in QtQuick. It’s the most challenging issue i have at this moment for this project.
All of the above is the justification for the lack of finished “QML Calendar” application. However, things are changing quite rapidly at this moment. I started re-creating the calendar with Qt 5.1 (QtQuick 2.1) and it’s progressing very fast and nice. I’m not going to make promises, but i should have it working like a year ago only with the new calendar components and Qt 5.1. Stay tuned for more status updates since i plan on posting them more often from now on.
Update: a completely unrelated update. Some people asked me to do something about the comment box since it was sometimes impossible to reply at all. Turns out that the WYSIWYG comment box was done by Crayon – the syntax highlighter plugin – where i apparently screwed a setting up. That is fixed now and you have the plain old comment box back. Which is how i wanted it anyway.