Ocean Mist

18 Feb 2009

And sometimes it’s not my bug

Posted by astromme

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.

Now with italicized text and different sizes for clarity

Now with italicized text and different sizes for clarity

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/

Subscribe to Comments

5 Responses to “And sometimes it’s not my bug”

  1. Something I’ve been wondering about when reading about this plasmoid…(no, I haven’t tried it myself yet) as good as it is having a plasmoid interacting with rtm I wonder if there is a possibility to extend this.

    What I mean is that it is great to have a plasmoid to read/change the status of the tasks that has been set at the website but it would be even greater if you could set up Kontact to use the same resource! And especially so for those that syncs Kontact data with a PDA.



  2. As Jonas points out, it would be very nice to generalize the UI and support multiple backends. I would like to use it as a frontend for Tracks (a Rails GTD implementation). Would it be possible to write the RTM connector as an akonadi resource and have the plasmoid use akonadi?



  3. I was trying out the latest version of the RTM plasmoid. I have found that it can be hard to read sometimes. I have two suggestions that might help with this. The first is to move the due date to the second line and then fade out the taggs in preference for the due date. This would give more space to the tasks on the first line. The second suggestions is to allow the font to be chosen so that a smaller font is used to display things. Again, helping with the not being able to see the whole task name. Great plasmoid though.


    Justace Clutter

  4. I’ve tried this latest version but it will crash plasma every time after getting the data.


    Thomas Coopman

  5. I made some library cleanups, which necessitate a rebuild/reinstall of librtm. If building/installing librtm, then the data engine then the plasmoid doesn’t fix the issue, respond and I’ll investigate.

    On the one hand it sucks to have to recompile multiple things because the library is still in flux. However, implementing much of the plumbing as a library will let me/others use rtm for other things, say a kde resource (i.e. usable in Kontact).

    I keep saying this, but I do want to stabilize librtm eventually.



Leave a Reply