1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
This document is meant to provide some documentation of rough consens
of where karm should be going and how things should be done.
It does not represent something set in stone. Things can be discussed
and changed.
---------------------------------------------------------------------
* karm should not interfere if the user wants to run multiple tasks at
the same time that add up to more that 100%.
It'd be nice though to have the possibility to have one task at a time
only (currently through double click).
Or to let tasks' shares add up to 100%. Maybe through the context menu
("share time with other task").
* tasks should update their own time and pass changes on down to the root.
The root is responsable for updating the status bar.
Subject: Re: [Kde-pim] karm: how tasks should work
From: Scott Monachello <[email protected]>
Date: 2002-10-26 9:38:23
On Thursday 24 October 2002 06:37 pm, tomas pospisek wrote:
> OK guys, I'm moving this into public space. I think we're open source so
> it's here where these things should be discussed. I hope citing your
> proposition in public is fine with you Scott. So here it comes,
> reformatted to fit into a mail:
>
> Scott Monachello propopsed [reformatted by tpo]
>
> > Requirements for Karm Subtask Functions
> >
> > This is how HEAD currently operates.
> > Id Description
> > ---------------------------------------------------------------------
> > 1 Karm shall provide a hierarchical structure of tasks. If a task
> > has at least one subtask it will be referred to as a parent task.
> > If a task has no children it will be referred to as a leaf task.
> > If a task has no parent tasks it will be referred to as a root
> > task.
> > 2 A new task can be created as a child of any existing task.
> > 2.1 If the parent had a timer active, it will continue to be active
>
> It depends on how you start it. If you double click it. Any other timer
> will be stopped and the new task started. If you start it through the
> start button, both tasks will be active. This a bug IMO. See at the bottom
> for my proposal.
>
> > 2.2 The session time for the parent will not be changed by adding
> > the new child task.
> > 2.3 The total time for the parent will not be changed by adding a
> > the new child task.
> > 3 Any task (parent, leaf, or root) may have an independent timer.
> > 4 The time (both session and total) for a parent will be the sum
> > of its independent timer and the sum of all of its child timers.
> >
> > Unstable Development
> > This is my proposal for how Unstable_Development should operate. I
> > changed 2.1 - 4 and added and added 2.2.1 and 1008.
> >
> > Id Description
> > ---------------------------------------------------------------------
> > 1 Karm shall provide a hierarchical structure of tasks. If a task
> > has at least one subtask it will be referred to as a parent task.
> > If a task has no children it will be referred to as a leaf task.
> > If a task has no parent tasks it will be referred to as a root
> > task.
> > 2 A new task can be created as a child of any existing task.
> > 2.1 If the parent had a timer active, it will be deactivated
> > 2.2 The session time for the parent will set to zero
> > 2.2.1 The session time for the child will be initialized to the last
> > session time of the parent.
> > 2.3 The total time for the parent will be set to zero.
> > 2.3.1 The total time for the parent will be initialized to the last
> > total time of the parent.
> > 3 Only a leaf task may have a timer. A parent may not have its own
> > timer.
> > 4 The time (both session and total) for a parent will be the sum
> > only of its child timers.
>
> I see where you want to go, but I think it's not the right direction for
> two reasons:
>
> 1. Let's say I'm working on karm - I have a generic task "karm". Now I
> start working on the docu and add a subtask "docu". Right now I can
> switch between a generic task "working on karm" and more specific
> subtask "docu". Times are added together at the task "karm". That makes
> sense IMO. If I don't want to be specific I can - if I do want to be
> more precise I can as well. With your proposal this is not possible any
> more.
>
> 2. You break current setups. People are (I guess) using karm for real life
> things. When you change the behaveour to what you propose this
> force them to reorganize their trees. As a user, personally I'm not
> looking forward having to do this.
>
> My proposition is:
>
> Id Description
> ---------------------------------------------------------------------
> 2.1 If a new task is double clicked or started with the start
> button the previous task is stopped.
So, only one task is ever active at one time, right? Tasks should be more like
radio boxes rather than check boxes.
> 2.1.1 If someone feels like it s/he can add an entry/functionality into
> the context menu of a task to have it share proportionally the
> time being stopped with other tasks currently running. All the
> times always add up to 100%.
> This can be useful when doing >1 task at a time (compiling and
> phoning f.ex.)
I've been thinking about something along these lines too. I think it's a good
idea but can't quite see how the interface should work.
>
> The rest stays the same as in HEAD.
>
> Additionaly I propose:
>
> Id Description
> ---------------------------------------------------------------------
> 5 Times can be dragged and dropped, whereby they get transferred and
> added to the destination.
> 6 We move to scheme where times have a beginning and an ending and
> not just an absolute value.
>
> Comments?
> *t
>
> PS: Please follow up to the mailing list.
Ok. So, I'll undo the changes related to:
* summing only leaf tasks
* disallowing edits on parent tasks
_______________________________________________
kde-pim mailing list
[email protected]
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
|