On Friday 22 August 2003 6:26 am, tomas pospisek wrote:

> * A KListView subclass that has a context menu that pops up
>   when clicking the RMB inside the header and presents you all the columns
>   which you can hide or show.

That sounds useful.

>   I did this because I want to have all the nice korganizer-todo
>   properties inside karm (and vice-versa), but I also want people to be
>   able to configure what todo properties they see so that it won't clobber
>   their screen.

I'm not sure about this idea.  Why make both gui's the same?  Won't this mean 
that we will have to work to keep KArm UI in sync with KOrganizer?  (For 
example, the drag-n-drop stuff Reinhold added?)  I'm not anxious to set this 
kind of expectation.  Why not just keep KArm simple--if they want access to 
all KOrg fields, they can edit the todo in KOrg.

In addition, I think there are fields that are useful in KArm that KOrganizer 
may never display; for example, an hourly budget for each task.  With this 
field, we could compute % complete, which KOrg does care about.

To me, there are reasons to keep them seperate.

> * A new subclass of QListViewItem that integrates a QCheckListItem
>   with Karm's running clock.
>
>   I did this because the Karm fraction loves being able to double click on
>   a task and having the task start/stop running and the Konqueror fraction
>   loves being able to double click a todo and be able to edit its
>   properties and click the checkbox and be done with a task.

This raises an interesting question--how to display complete tasks in KArm.  
There was some discussion recently here about the same issue in KOrganizer  
(grey vs. strikeout vs.  no change).  Previously, when you were done with a 
task you could delete it.  The way I implemented karmstorage, when you delete 
a task, it's history is deleted.

Personally, I find the checkbox overlaid on the clock to be confusing 
visually.  And if I understand your chart, double-clicking in different areas 
on the same line produces a different result.  I don't think the increase in 
functionality is worth the added complexity to the UI.

>   The idea is here again to eventually integrate korganizer and karm.
>
>   So I've integrated the checkbox with the clock:
>
>   * if you single click the clock/checkbox you check the checkbox
>   * if you double click the clock/checkbox you start/stop a task
>   * if you double click the tastk you edit the task properties
>
>   You can find an illustrated example here:
>
>   http://sourcepole.ch/tpo/ktimerchecklistitem.png
>
>
>   Please speak up if you think this is a really bad idea. Otherwise I'd
>   like to proceed and commit this to CVS so people can play with it. The
>   next step would be merging of korganizer's todo list classes with karms
>   and moving them to llibkdepim (and of course integrating Mark's huge
>   patch)

My vote would be to wait.  The issue of more tightly integrating the UI with 
KOrganizer needs more thought, I think.  :)  Especially with a Sep 1 feature 
freeze and a Sept 8th alpha release!

I think I'll go ahead and commit my karmstorage patch it if I don't hear from 
Stephan by Thursday (I've sent him a private email, which I forwarded to 
you).  I assume if I have everything working by the alpha release (on the 
8th), no-one will mind.

Regards,

Mark
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/