[Korganizer-devel] Todo view

Thomas Thrainer tom_t at gmx.at
Wed Feb 13 16:53:52 CET 2008


Hello

Allen pointed me to the todo view, which is currently in a quite bad shape.

So I looked into it, and I came to the conclusion that I don't like the code 
at all :-(.
There are 4 treeview from which either one or three are displayed, but all of 
them have to be kept in sync. Just by reading over the code I've seen that 
this would probably not really work very well.

Furthermore, the code for getting and manipulating data is mixed with the 
display stuff. Not very nice lecture IMHO.

So, I had quite a hard time to get familiar with the code, and as I said, I 
didn't like it very much. 

So I thought about alternatives (because it has to be ported anyway). In the 
same time I read about the model/view architecture of QT, and thought it 
would be nice to go into that a litte bit.
So I decided to learn something about QT's model/view archtecture and QT in 
general (I am not really experienced in QT and KDE programming...). So here 
is what I thought of:

Create a model wich presents the data from the resources. It creates the tree 
structure of the todo's and provides data about all the entries. That's done.

The model also should do all the editing/updating stuff (not the visible 
thing, but the backgroud work). That's not done yet.
Drag and drop should also be handled by the model, but that's not implemented 
either.

The QTreeView widget can be used to display the data of the model. That works 
quite well. Also, delegates can be written to display for example the 
progress bar. And, which is quite cool, you can edit the todo's inplace. I 
attach a screenshot with a slider to change the progress of a todo (which 
does not actually change it now, because the model is not finished yet).

And finally, I think it would be quite easy to write proxy models which filter 
the todo's into these 3 proposed categories (my todo, others todo and I can't 
remember what). It would be really easy then to create 3 tree views, which 
just use another proxy model on the same model.

I attach the patch I am working with. That's really only my working copy, so 
there is a lot of cleanup needed ;-). I just commented the old code for now, 
the new approach is basically a rewrite (with some code copied over). I also 
attach a screenshot of the todo view.

What do you all think about this approach? Is it sensible to do it this way? 
Any suggestions?

Thomas

PS.: If somebody knows how to get rid of the highlighted checkbox in the 
screenshot, drop me a line. I think there is a problem in the default 
QItemDelegate when it is only displaying an icon, and nothing else...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: todo.png
Type: image/png
Size: 72795 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/korganizer-devel/attachments/20080213/ab0cb169/attachment-0001.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: todo.diff
Type: text/x-diff
Size: 4522 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/korganizer-devel/attachments/20080213/ab0cb169/attachment-0001.bin 


More information about the Korganizer-devel mailing list