[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Karm patch
From:       thorsten () staerk ! de
Date:       2006-05-18 17:51:24
Message-ID: 46528.155.56.68.221.1147974684.squirrel () mail ! staerk ! de
[Download RAW message or body]

> Hi,
>
>       Discussion with Thorsten on #kontact resulted in both of us
> agreeing that certain issues that I pointed out were actually bugs
> since they do what they are supposed to do. Check this [1]  firstly.
>
yes - displayed time tasks are always rounded up. Annoying.

>       Another thing that I noticed that a user could timed a parent
> task and its subtasks at the same time. These times were added to the
> total times of the parent task. IMHO this is not correct.
>
>       Here's example -
>        say A == Develop ToDo application. (top level task)
>            B == Design Backend
>            C == Design UI using QtD.
>            D == Work on Interview for Backend and connect to mail UI
>            E == Test application.
>
>       [B,C,D,E are subtasks of A].
>
>       Now its quite possible that the user is doing B and C together.
> And hence they are being clocked together. So at the end of 1 hour
> (considering that both the tasks were started at the same time) the
> total cumulative time would be 2 hours and that would be "billable".
> Karm, as it stands now, a user could very well have had even started
> the timer for A (the top task). Hence at the end of 1 hour the total
> billable hour would be 3 hours. Now the problem is A is just a place
> holder in this situation. It makes no sense to clock that.
>
>       One argument can be that why allow two sub-tasks at one time for
> a single top lever tasks. But there can be many situations where that
> kind of scenario be applied. Say working on two different modules
> belonging to the same project. Quite possible.
>
>       A solution that was thought of was that to "not" allow the user
> to start timer for a top level task that had subtasks running. Another
> thing that Till suggested to me on irc was that it would be nice that
> if we don't disable top-level tasks from running at all, since he told
> there can be situations where the just "placeholder" needs to be timed
> instead of the sub-tasks. Instead disable them from running only if
> one of its sub-tasks is already running.

Yes, as long as I am looking for which subtask to do, I have the parent
task timing.
>
>       This also called for a simple "side effect" case. What would
> happen if the user would run a top-level task first and the try to run
> the sub-task? That called for automatic stopping of top-level task
> when the sub-task was started.

For normal users, this is more confusing than before. You can switch on
"Unitasking" (only one timer at a time) and get rid of all these problems.
Yes, then you do not have the possibility to time two subtasks. But let's
avoid confusion.
>
>       The attached patch can do all the above.
>
>       @Thorsten : I have implemented the Task::time() method. Please
> review. Its there in this patch. So you might ignore the earlier file
> that I sent.
>
>       Please review this patch and if oke please apply it. I must
> admit that I have added a few kdebugs and they are there in the patch.
> Hope that is not too much of a problem.
>
>       [1] http://bugs.kde.org/show_bug.cgi?id=127385
>
>       Cheers!
>
> Pradeepto
> --
> The KDE Project : http://www.kde.org
> KDE India : http://in.kde.org
> Mailing List : http://mail.kde.org/mailman/listinfo/kde-india
> _______________________________________________
> kde-pim mailing list
> kde-pim@kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> kde-pim home page at http://pim.kde.org/

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]