Merge lp:~bertrand-rousseau/gtg/get_due_date into lp:~gtg/gtg/old-trunk
| Status: | Merged |
|---|---|
| Merged at revision: | 1211 |
| Proposed branch: | lp:~bertrand-rousseau/gtg/get_due_date |
| Merge into: | lp:~gtg/gtg/old-trunk |
| Diff against target: |
309 lines (+69/-54) 4 files modified
CHANGELOG (+1/-0) GTG/core/task.py (+44/-18) GTG/gtk/browser/taskbrowser.glade (+24/-24) GTG/gtk/editor/editor.py (+0/-12) |
| To merge this branch: | bzr merge lp:~bertrand-rousseau/gtg/get_due_date |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Izidor Matušov | code, running | Approve | |
|
Review via email:
|
|||
Description of the change
Remove the implicit interpretation of due date through get_due_date:
With this patch, GTG uses the actual value of the task object's due date
when accessing it through get_due_date.
It seems to me that it's saner than the current mechanism that relies
on an on-the-fly interpretation when accessing the due date. Indeed,
this can hide mismatches between the stored value and the returned due
date.
Typical example: a parent task with due date A and a child task
with no due date: the child has no due date set, but get_due_date
will return 'A'.
Now, you get what you really have stored, but therefore it's up to the
code to make sure you store a correct value!
Therefore, from now on all code dealing with tasks due dates and
tasks relations MUST be written so that the due dates are always set
correctly (=they respect the date constraints). This is actually not
a big deal since most of this is actually cared for by set_due_date().
set_due_date() has thus been slightly modified (pursuing previous
work by Nimit Shah), so that when you set/update the due date, all
related tasks dates are modified to respect the constraints.
However, D&D'ing tasks can still create situations where a parent task due
date and its child due date are not compatible. This cannot be fixed
now since D&D is done in liblarch and there are no hooks available
from the GTG code to handle tasks updates when reparenting them...
This patch also means that from now on, undefined due date are presented
explicitely in the list as not being set, even when constrained by a
parent. Therefore, it's up to the user to explicitely define it if needed
(which she/he can do by directly setting the due date of the task, or by
setting the due date of the parent). It's possibly more work for her/him,
but at least the outcome is clear and therefore predictable/usable: explicit
is always better than implicit.
Note: some code from the task editor that checks if the start and due
date are compatible has been removed, since it's done in set_due_date
now.
| Izidor Matušov (izidor) wrote | # |
| Bertrand Rousseau (bertrand-rousseau) wrote | # |
I reviewed your changes and I like the proposed behavior better. There goes nitpicking:
get_constrained
The correct code in editor should be:
if date_kind == GTGCalendar.
date = self.task.
Otherwise it uses start date for the calendar - regression.
You've changed the description from "clear due date" into "reset to default". I am not sure if it is a good idea:
1, it is inconsistent within due_date -> the button in calendar is still "clear"
2, it is inconsistent with start_date -> why you clear start_date but reset due_date? In my opinion, it reveals too much implementation details to a user.
And as usually, the name of the program is intranslatible after using Glade :-/
It looks good, fix those small details and you have my aproval.