GNOME Bugzilla – Bug 132357
Lag time unit should be more flexible
Last modified: 2005-02-19 15:07:58 UTC
The lag functionality resorts to hours and not the default period of the task or rather does not retain its own unit of measure (i.e same as how the Work field is parsed). The field should do this: It should adopt the size of the period of the task (e.g. days or hours depending upon when it is set) and remember this in the Text field by retaining the 'd' or 'h' value. You should be able to add 1d or 1h or even 1w or even 5min or 30sec if the Project Properties allowed for such large or small units of measure. I actual prefer if it defaulted and displayed to what I expected i.e. units of the predecessor task OR I was able to input text strings like 1d or 1w etc. Rgds. Lincoln. ps: Having minutes (or seconds) is not that silly as its an idea I have to have Project plans run what I call 'missions'. These are precisely timed projects e.g. doing a trade show with 15 minute slots for speakers as well as lunches, tea and 5 minutes long Q+A. You'll find that the normal 1 day or 1 hour granularity of all other project tools really gets in the way of these 'missions' e.g. when you have speaker slots of 10 to 15 minutes with 2 minute handovers of a podium.
In order to fix this bug: 1. change the spinbutton for setting lag to a regular entry (with glade, the file is planner/data/glade/task-dialog.glade) 2. search through planner/src/planner-task-dialog.c for "lag" and update the code to handle an entry instead of spinbutton. 3. copy code from task_tree_parse_time_string in planner-task-tree.c to parse the string (that function should probably be put in planner-format.c and shared)
Changing summary to better reflect the issue. The unit should work just like the duration for tasks, i.e. parse the input and output days or minutes etc depending on the length of the lag.
*** Bug 132379 has been marked as a duplicate of this bug. ***
re: 3. copy code from task_tree_parse_time_string in planner-task-tree.c to parse the string (that function should probably be put in planner-format.c and shared) May be a bit hard as it requires the tree to get the project calendar to derive the seconds per day. I'll see.
We also need to do the following, Make Lag elased time not working time (comments please on this) - maybe we have a Project-wide option of "Lag Units are Elapsed" or Lag Units are Worked" Re-display the lag field with the same units that the user inputted or at least redisplay this as something meaningfull. I suggest we could round to nearest non-zero unit of measure e.g. if user inputs 0d1h we turn into 3600 seconds but redisplay as 1h if user inputs 1d1h we turn into 90000 seconds and redisplay as 1d 1h Currently the algorithm would take 1 hour and display as 1 and 1 day 1 hour and display as 9 because it uses 8 hour days.
*** Bug 151601 has been marked as a duplicate of this bug. ***
The unit now works as the other durations in planner. Lag is currently always "wall time", adding or changing to work time should be tracked in another bug if we want that.