And sometimes it’s not my bug

It’s time for another update on my work on the remember the milk plasmoid. It’s shaping up nicely, and I’m often amazed at how nicely the different Qt and KDE libraries fit together. However, there are those times when I bang my head against a wall for hours trying to fix some bug or implement some feature only to discover that it wasn’t my problem in the first place.

This happened to be the case with drag and drop support for the plasmoid. It started off with an itch to have basic drag and drop support to change a task’s priority. I wanted to be able to move around my tasks visually instead of going into an editor and changing the priority. It turns out that QGraphicsScene/QGraphicsView had some bugs when dealing with widgets on canvas. For those who haven’t worked with woc, it’s a great idea. Putting any graphical widget onto a canvas that already has support for transformations and scaling and the works is a wonderful thing to be able to do, and it allows for things like Plasma to happen without lots of work reinventing (or reimplementing) the wheel. However, Qt 4.4 was the first release with WoC support and suffered from some bugs. I was quite frustrated, not understanding why my dragged task was offset, or why I was never getting any drop events, when I finally decided to see if the Qt 4.5 RC fixed it. After a rebuild I restarted plasma, and much to my surprise, it all worked! That’s another +1 to 4.5 from me, as drag and drop for rtm tasks is impossible without it.

In other news, I’ve gotten some great feedback from some brave souls willing to test drive the plasmoid. Thanks guys, and sorry about the mismatched commits that was leaving you all stuck at “refreshing” after authenticating. But anyways, your suggestions have lead to a few fixes already and have also got the ball rolling regarding displaying more complex data (and searches). As you can see in the screenshot, the tags and the due date text items (on the right side of the tasks that have them) are now italicized and smaller than the task name. Hopefully this should provide some visual hints to what a user needs to read to get the overview of his tasks (hint… that would be the task titles). I’ve also ellipsized (not a word, but you get the idea) the ends of tasks that are too long to show in the width of the applet. This works correctly whether or not the task has a due date and in my opinion vastly improves the visual look of the tasks.

But hiding part of the task leads to the question of how does the user see the full task name? At the moment, clicking on the task will bring up the edit window, which then shows the task name at the very top of the applet (where “Remember The Milk Tasks” is currently), but this isn’t good enough for me. I’ve got a few options for this. I could provide a tooltip upon mouse hover, but that is ugly for tablet pc users (hovering the pen in one place is not easy), and it also breaks the visual identity of the applet. I could also show the task on two lines (eliding it if it’s longer than that) which would work as well, but would add a lot of visual information and clutter to the applet.

I’m not happy with either of the above options, but I think I can tackle multiple problems with the addition of a larger task view. Ideally, for each task I would show a little “show more” arrow upon mouseover, which, when clicked, would smoothly expand the task into a more detailed view. This view would show the full task name and other data such as the notes attached to the task, whether it’s been postponed, the location and other people set, etc… This might even become the editor interface, replacing the faded in overlay that I have currently. The problem is that this might be difficult with my current implementation of the tasks view widget. I’m currently using a QStyledItemDelegate and a standard Plasma::TreeView to show the tasks, but I’m wondering if it would be better to move to an all QGraphicsScene based approach. I’ve heard that QGraphicsView layouts had some serious issues in 4.4, but hopefully these are also fixed with 4.5. Moving to a QGraphicsView would also allow some nicer animations as I wouldn’t be held back by the limitations of widgets on canvas. But anyways, I’m happy that I’ve even gotten this far, this is one of my first larger projects and there is certainly time for enhancements.

One last little thing. I made a blog post earlier on some ideas for a linux backup system made for end users. It’s slightly off topic from KDE and nowhere near a reality, and so I didn’t post it on the planet. However, if you’re interested in chiming in with your thoughts and ideas about backups, please feel free to read it and add your comments. http://blog.chatonka.com/2009/02/timevaultng-structure-document-draft/