Hi all,

I've been splitting the existing "start date/time" attribute of tasks
into a "planned start date/time" and an "actual start date/time". Not
a small change, but not an overly complex one either. However, it made
me realize we handle changes to attributes in a certain way and I'm
not sure it's the best way. Let me explain what currently happens when
an attribute is changed:
1. User clicks a menu item or a toolbar button.
2. This activates a UICommand (user interface command; should really
be renamed to UIAction to better distinguish it from "real" commands).
3. The UICommand creates a Command (for example
TaskMarkCompletedCommand) and calls its do() method.
4. The Command saves the state it needs to be able to undo itself and
then makes the change.
5. When a change to one attribute of a task (or other domain object)
affects another attribute of that same task (a) or another attribute
of another task (b), the changes are made by the method of the first
task and not by the Command. Example of a) setting the percentage
complete to 100 is done by the setPercentageComplete() method and that
method also invokes setCompletionDateTime() to change the completion
date of the task. Example of b) marking a task completed also marks
all of its children completed. This is done by
setCompletionDateTime().

Note how in step 4 all state that is needed to undo the change is
saved by the Command class while all the work is done by the domain
objects themselves in step 5. This means there is an implicit
dependency between step 4 and 5. You can't change stuff done in step 5
without also changing the state that is saved in step 4. Or, as we do
in many cases, save too much state.

So my first question is whether it would be a good idea to move a big
chunk of the code in the set* methods to the different Commands. Or,
does this responsibility belong somewhere else entirely?

The other related question is whether it is actually a good idea to
change related domain objects when one domain object changes. For
example, when a task is completed we also mark all the subtasks
completed. A different approach could be to not change any of the
related domain objects, but instead make the getter more intelligent.
So the Task.completed() method would return True when the task itself
is completed or when the percentage complete is 100 or when the parent
task is completed. The advantage of this is that my first question
sort of disappears: both the setters and the Commands could be kept
simple. The disadvantage may be that the getters get more complex and
possibly slower?

I'd appreciate any suggestions, thoughts, references to articles maybe, etc...

Thanks, Frank

Hi Jérôme,

I think I'm pretty much done with adding the actual start date time
attribute. Can you take a look at the SyncML and iOS syncing part?
Does it need to be adapted?

Cheers, Frank

Le 15 janv. 2012 à 23:06, Frank Niessink a écrit :

> Hi Jérôme,
>
> I think I'm pretty much done with adding the actual start date time
> attribute. Can you take a look at the SyncML and iOS syncing part?
> Does it need to be adapted?

Don't know yet, but I already had this in my pipe; I'll make some testing.

Cheers
Jérôme

 

Hi all,

I've been splitting the existing "start date/time" attribute of tasks
into a "planned start date/time" and an "actual start date/time". Not
a small change, but not an overly complex one either. However, it made
me realize we handle changes to attributes in a certain way and I'm
not sure it's the best way. Let me explain what currently happens when
an attribute is changed:
1. User clicks a menu item or a toolbar button.
2. This activates a UICommand (user interface command; should really
be renamed to UIAction to better distinguish it from "real" commands).
3. The UICommand creates a Command (for example
TaskMarkCompletedCommand) and calls its do() method.
4. The Command saves the state it needs to be able to undo itself and
then makes the change.
5. When a change to one attribute of a task (or other domain object)
affects another attribute of that same task (a) or another attribute
of another task (b), the changes are made by the method of the first
task and not by the Command. Example of a) setting the percentage
complete to 100 is done by the setPercentageComplete() method and that
method also invokes setCompletionDateTime() to change the completion
date of the task. Example of b) marking a task completed also marks
all of its children completed. This is done by
setCompletionDateTime().

Note how in step 4 all state that is needed to undo the change is
saved by the Command class while all the work is done by the domain
objects themselves in step 5. This means there is an implicit
dependency between step 4 and 5. You can't change stuff done in step 5
without also changing the state that is saved in step 4. Or, as we do
in many cases, save too much state.

So my first question is whether it would be a good idea to move a big
chunk of the code in the set* methods to the different Commands. Or,
does this responsibility belong somewhere else entirely?

The other related question is whether it is actually a good idea to
change related domain objects when one domain object changes. For
example, when a task is completed we also mark all the subtasks
completed. A different approach could be to not change any of the
related domain objects, but instead make the getter more intelligent.
So the Task.completed() method would return True when the task itself
is completed or when the percentage complete is 100 or when the parent
task is completed. The advantage of this is that my first question
sort of disappears: both the setters and the Commands could be kept
simple. The disadvantage may be that the getters get more complex and
possibly slower?

I'd appreciate any suggestions, thoughts, references to articles maybe, etc...

Thanks, Frank

Le 15 janv. 2012 à 22:07, Frank Niessink a écrit :

> Hi all,
>
> I've been splitting the existing "start date/time" attribute of tasks
> into a "planned start date/time" and an "actual start date/time". Not
> a small change, but not an overly complex one either. However, it made
> me realize we handle changes to attributes in a certain way and I'm
> not sure it's the best way. Let me explain what currently happens when
> an attribute is changed:
> 1. User clicks a menu item or a toolbar button.
> 2. This activates a UICommand (user interface command; should really
> be renamed to UIAction to better distinguish it from "real" commands).
> 3. The UICommand creates a Command (for example
> TaskMarkCompletedCommand) and calls its do() method.
> 4. The Command saves the state it needs to be able to undo itself and
> then makes the change.
> 5. When a change to one attribute of a task (or other domain object)
> affects another attribute of that same task (a) or another attribute
> of another task (b), the changes are made by the method of the first
> task and not by the Command. Example of a) setting the percentage
> complete to 100 is done by the setPercentageComplete() method and that
> method also invokes setCompletionDateTime() to change the completion
> date of the task. Example of b) marking a task completed also marks
> all of its children completed. This is done by
> setCompletionDateTime().
>
> Note how in step 4 all state that is needed to undo the change is
> saved by the Command class while all the work is done by the domain
> objects themselves in step 5. This means there is an implicit
> dependency between step 4 and 5. You can't change stuff done in step 5
> without also changing the state that is saved in step 4. Or, as we do
> in many cases, save too much state.
>
> So my first question is whether it would be a good idea to move a big
> chunk of the code in the set* methods to the different Commands. Or,
> does this responsibility belong somewhere else entirely?

IMO this belongs to the Commands. In a ideal world no setter should have
"side-effects" on other properties. In the real world it's sometimes easier to
break that rule. Whatever makes the code simpler is good even if it's not
following the ideal :)

Moving this stuff to the Commands raises some other questions though. For
instance, should the Command that marks a task complete itself use the setters
of children/parent tasks, or use other Commands ? In the second case we may end
up with fewer, simpler Command classes but the undo would be counter-intuitive
(unless we somehow aggregate commands in batches).

>
> The other related question is whether it is actually a good idea to
> change related domain objects when one domain object changes. For
> example, when a task is completed we also mark all the subtasks
> completed. A different approach could be to not change any of the
> related domain objects, but instead make the getter more intelligent.
> So the Task.completed() method would return True when the task itself
> is completed or when the percentage complete is 100 or when the parent
> task is completed. The advantage of this is that my first question
> sort of disappears: both the setters and the Commands could be kept
> simple. The disadvantage may be that the getters get more complex and
> possibly slower?

That would definitely make some getters horribly complex. And confuse the iPhone
app since it looks up task states through a SELECT in an SQL database :)

Cheers
Jérôme

2012/1/16 Jérôme Laheurte <fraca7@...>:
>
> Le 15 janv. 2012 à 22:07, Frank Niessink a écrit :

>> So my first question is whether it would be a good idea to move a big
>> chunk of the code in the set* methods to the different Commands. Or,
>> does this responsibility belong somewhere else entirely?
>
> IMO this belongs to the Commands. In a ideal world no setter should have
"side-effects" on other properties. In the real world it's sometimes easier to
break that rule. Whatever makes the code simpler is good even if it's not
following the ideal :)

Agreed. However, it's not necessarily simpler. For example, look at
the ToggleCategoryCommand in command.categorizableCommands.py that
already does most of the work itself:
http://taskcoach.svn.sourceforge.net/viewvc/taskcoach/branches/Release1_3_Branch\
/taskcoach/taskcoachlib/command/categorizableCommands.py?revision=5096&view=mark\
up

Pretty well documented, rather clean, but not simple.

> Moving this stuff to the Commands raises some other questions though. For
instance, should the Command that marks a task complete itself use the setters
of children/parent tasks, or use other Commands ? In the second case we may end
up with fewer, simpler Command classes but the undo would be counter-intuitive
(unless we somehow aggregate commands in batches).

Batching commands is a possibility in theory, but I'd rather not go
there. Too complex for my simple brain.

>> [smarter getters]. The disadvantage may be that the getters get more complex
and
>> possibly slower?
>
> That would definitely make some getters horribly complex. And confuse the
iPhone app since it looks up task states through a SELECT in an SQL database :)

OK, so it sounds that making the Commands do most of the work in
combination with keeping the getters simple sounds like a best
strategy?

Cheers, Frank

Le 17 janv. 2012 à 00:00, Frank Niessink a écrit :

> 2012/1/16 Jérôme Laheurte <fraca7@...>:
> >
> > Le 15 janv. 2012 à 22:07, Frank Niessink a écrit :
>
> >> So my first question is whether it would be a good idea to move a big
> >> chunk of the code in the set* methods to the different Commands. Or,
> >> does this responsibility belong somewhere else entirely?
> >
> > IMO this belongs to the Commands. In a ideal world no setter should have
"side-effects" on other properties. In the real world it's sometimes easier to
break that rule. Whatever makes the code simpler is good even if it's not
following the ideal :)
>
> Agreed. However, it's not necessarily simpler. For example, look at
> the ToggleCategoryCommand in command.categorizableCommands.py that
> already does most of the work itself:
>
http://taskcoach.svn.sourceforge.net/viewvc/taskcoach/branches/Release1_3_Branch\
/taskcoach/taskcoachlib/command/categorizableCommands.py?revision=5096&view=mark\
up
>
> Pretty well documented, rather clean, but not simple.
>
> > Moving this stuff to the Commands raises some other questions though. For
instance, should the Command that marks a task complete itself use the setters
of children/parent tasks, or use other Commands ? In the second case we may end
up with fewer, simpler Command classes but the undo would be counter-intuitive
(unless we somehow aggregate commands in batches).
>
> Batching commands is a possibility in theory, but I'd rather not go
> there. Too complex for my simple brain.
>
> >> [smarter getters]. The disadvantage may be that the getters get more
complex and
> >> possibly slower?
> >
> > That would definitely make some getters horribly complex. And confuse the
iPhone app since it looks up task states through a SELECT in an SQL database :)
>
> OK, so it sounds that making the Commands do most of the work in
> combination with keeping the getters simple sounds like a best
> strategy?

Sounds fine to me.

Cheers
Jérôme

Hi Jérôme,

This page seems out of date:
http://www.fraca7.net/TaskCoach-packages/latest_bugfixes.py. Is the
build bot down?

Thanks, Frank

2012/1/16 Jérôme Laheurte <fraca7@...>:
>
> Le 15 janv. 2012 à 23:06, Frank Niessink a écrit :
>
>> I think I'm pretty much done with adding the actual start date time
>> attribute. Can you take a look at the SyncML and iOS syncing part?
>> Does it need to be adapted?
>
> Don't know yet, but I already had this in my pipe; I'll make some testing.

Did you have a chance to take a look? I'd like to release 1.3.5 today
if possible.

Thanks, Frank

2012/1/24 Frank Niessink <frank@...>:
> 2012/1/24 Jérôme Laheurte <fraca7@...>
>>
>>
>>
>> Please tell me when you have downloaded the release; I must reboot the
>> server. Disk problems it seems…
>
>
> 6 more minutes...

Done, go ahead and reboot :-)

Thanks, Frank

Le 24 janv. 2012 à 21:09, Frank Niessink a écrit :

> 2012/1/24 Frank Niessink <frank@...>:
>> 2012/1/24 Jérôme Laheurte <fraca7@...>
>>>
>>>
>>>
>>> Please tell me when you have downloaded the release; I must reboot the
>>> server. Disk problems it seems…
>>
>>
>> 6 more minutes...
>
> Done, go ahead and reboot :-)

Okay, thanks

Cheers
Jérôme

Le 24 janv. 2012 à 21:09, Frank Niessink a écrit :

> 2012/1/24 Frank Niessink <frank@...>:
>> 2012/1/24 Jérôme Laheurte <fraca7@...>
>>>
>>>
>>>
>>> Please tell me when you have downloaded the release; I must reboot the
>>> server. Disk problems it seems…
>>
>>
>> 6 more minutes...
>
> Done, go ahead and reboot :-)

Everything's back to normal, I hope. And the PPAs for release 1.3.6 actually
worked. I'm getting kind of sick of them :)

Cheers
Jérôme

It's not used any more is it ?

Cheers
Jérôme

2012/2/4 Jérôme Laheurte <fraca7@...>:
> It's not used any more is it ?

Yup. I just removed it.

Thanks, Frank

Frank, I see you tried to trigger a release build yesterday. The VMs were
automatically paused because the disk was full :( It should work again now.

Cheers
Jérôme

Hi Jérôme,

2012/2/25 Jérôme Laheurte <fraca7@...>:
> Frank, I see you tried to trigger a release build yesterday. The VMs were
automatically paused because the disk was full :( It should work again now.

Thanks. I'll do a release today.

Cheers, Frank

The buildbot will be down for a few days. I must replace the disk and reinstall,
it's dying…

Cheers
Jérôme

2012/2/28 Jérôme Laheurte <fraca7@...>:
> The buildbot will be down for a few days. I must replace the disk and
reinstall, it's dying…

I've signed up for jenkinshosting.com. It's free for open source
projects and I know from experience that Hudson/Jenkins is a nice
tool. Unfortunately, I couldn't see from the homepage what kind of
slaves they support so I signed up to do some testing.

Cheers, Frank

Le 28 févr. 2012 à 20:24, Frank Niessink a écrit :

> 2012/2/28 Jérôme Laheurte <fraca7@...>:
>> The buildbot will be down for a few days. I must replace the disk and
reinstall, it's dying…
>
> I've signed up for jenkinshosting.com. It's free for open source
> projects and I know from experience that Hudson/Jenkins is a nice
> tool. Unfortunately, I couldn't see from the homepage what kind of
> slaves they support so I signed up to do some testing.

Interesting. Seems like they're running their own continuous integration
software. Isn't there any "public" view for projects that use this ? They don't
mention any open source project using them it seems.

Cheers
Jérôme

2012/3/1 Jérôme Laheurte <fraca7@...>:
>
> Interesting. Seems like they're running their own continuous integration
software. Isn't there any "public" view for projects that use this ? They don't
mention any open source project using them it seems.

The website is a bit low on information, indeed. I have only had an
automated email after my request for an account. No credentials
received yet...

Cheers, Frank

Hi all,

It's only March and Task Coach has already been downloaded over 250K
times. That's cool, but it also generates quite some bug reports,
questions, etc. We could really use some help with bug fixing,
development, user support, etc. Is there anyone here that has a few
hours of spare time (per week/month) to spend on this noble cause?

Thanks, Frank

Hi,

when updating to the current tip of Task Coach (in branch
Release1_3_Branch), I got several conflicts due to .pyc files in
taskcoach/taskcoachlib/thirdparty/apscheduler/ . Is it really a good
idea to keep these files in the SVN?


Cheers

Kirill

2012/3/21 Kirill Müller <mail@...>:
> Hi,
>
> when updating to the current tip of Task Coach (in branch
> Release1_3_Branch), I got several conflicts due to .pyc files in
> taskcoach/taskcoachlib/thirdparty/apscheduler/ . Is it really a good
> idea to keep these files in the SVN?

They got included by accident. I removed them from subversion again so
I'm surprised you get a conflict. I'll check tonight.

Cheers, Frank