~bertrand-rousseau/gtg/get_due_date

« back to all changes in this revision

Viewing changes to GTG/gtk/editor/editor.py

  • Committer: Bertrand Rousseau
  • Date: 2012-06-10 19:10:54 UTC
  • Revision ID: bertrand.rousseau@gmail.com-20120610191054-cayshux6jtc1evaj
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.

Show diffs side-by-side

added added

removed removed

Lines of Context:
356
356
                self.task.set_due_date(datetoset)
357
357
            elif data == "closed":
358
358
                self.task.set_closed_date(datetoset)
359
 
 
360
 
            # Set the due date to be equal to the start date
361
 
            # when it happens that the start date is later than the due date
362
 
            start_date = self.task.get_start_date()
363
 
            due_date = self.task.get_due_date()
364
 
            if start_date and (start_date > due_date):
365
 
                self.task.set_due_date(self.task.get_start_date())
366
359
        else:
367
360
            #We should write in red in the entry if the date is not valid
368
361
            widget.modify_text(gtk.STATE_NORMAL, gtk.gdk.color_parse("#F00"))
371
364
    def on_date_pressed(self, widget, date_kind):
372
365
        """Called when a date-changing button is clicked."""
373
366
        if date_kind == GTGCalendar.DATE_KIND_DUE:
374
 
            date = self.task.get_due_date()
375
 
            start_date = self.task.get_start_date()
376
 
            due_before_start = start_date and start_date > date
377
 
 
378
 
            if not date or due_before_start:
379
 
                date = self.task.get_start_date()
 
367
            date = self.task.get_start_date()
380
368
        elif date_kind == GTGCalendar.DATE_KIND_START:
381
369
            date = self.task.get_start_date()
382
370
        elif date_kind == GTGCalendar.DATE_KIND_CLOSED: