gmane.comp.sysutils.pim.taskcoach.devel

Jerome Laheurte | 20 Aug 13:20

Difficult bug


Hi, Frank. I found a bug and I'm at loss as to how to fix it; I see 
several solutions but they may have other impacts...

The bug: Start with an empty file, create a category, then a 
subcategory, then a task. Edit the parent category and click OK. Edit 
the task. The result:

   File 
"/home/jla/WinHome/dev/fraca7/taskcoach-trunk/taskcoachlib/gui/dialog/editor.py", 
line 531, in getCategoryWithIndex
     category = children[i]
IndexError: list index out of range

After some digging, I found out that when the category's state is 
saved, patterns.Composite makes a copy of the children. Thus, when the 
edit is undone, the category's children are replaced with copies. But 
the global list of categories keeps the old versions.

As default object comparison is based on id, a category and its copy 
are considered different and bad things happen.

First thought: overload __contains__ in Sorter to compare items 
according to their __id. This fails because the copy generates a new 
__id (and I saw a comment about that so I guess it's intended). Would 
keeping the __id in a copy break something ? Does this fix other 
potential bugs due to the same root ?

Second thought: avoid copying in __getstate__, just keep the original 
instances. I'm pretty sure this will have side effects, though a

(Continue reading)

Frank Niessink | 20 Aug 20:49

Re: Difficult bug

Hi Jérôme,

2008/8/20 Jerome Laheurte <fraca7@...>:
>
> Hi, Frank. I found a bug and I'm at loss as to how to fix it; I see
> several solutions but they may have other impacts...
>
> The bug: Start with an empty file, create a category, then a
> subcategory, then a task. Edit the parent category and click OK. Edit
> the task. The result:

[snip]

I must be missing something but I don't see the exception when using
the trunk. Should I add the task to the parent or child category? When
you say edit, does it matter what I change?

Thanks, Frank

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:

(Continue reading)

Jerome Laheurte | 21 Aug 09:21

Re: Difficult bug

On Wed, 20 Aug 2008, Frank Niessink wrote:

> Hi Jérôme,
>
> 2008/8/20 Jerome Laheurte <fraca7@...>:
>>
>> Hi, Frank. I found a bug and I'm at loss as to how to fix it; I see
>> several solutions but they may have other impacts...
>>
>> The bug: Start with an empty file, create a category, then a
>> subcategory, then a task. Edit the parent category and click OK. Edit
>> the task. The result:
>
> [snip]
>
> I must be missing something but I don't see the exception when using
> the trunk. Should I add the task to the parent or child category? When
> you say edit, does it matter what I change?

No, actually I don't change anything, just click on OK. Maybe there's 
something you don't do exactly like me, let's detail:

  * Start with a new file (to be sure, I also removed my .ini file)
  * Create a newt category using the toolbar button
  * Select it
  * Create a new subcategory using the toolbar button
  * Create a new task using the toolbar button
  * Double-click on the parent category
  * In the category edit dialog, click OK
  * In the main toolbar, click on the Undo button

(Continue reading)

Jerome Laheurte | 21 Aug 12:44

Re: Difficult bug


Same result under Windows, using Python 2.4/wxPython 2.8.7.1 and 
Python 2.5/wxPython 2.8.7.1.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/taskcoach-dev/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:taskcoach-dev-digest@... 
    mailto:taskcoach-dev-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    taskcoach-dev-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Frank Niessink | 21 Aug 18:08

Re: Difficult bug

2008/8/21 Jerome Laheurte <fraca7@...>:
> No, actually I don't change anything, just click on OK. Maybe there's
> something you don't do exactly like me, let's detail:

Now I see it too. I'll look into it tonight (when the kids are sleeping 

Cheers, Frank

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/taskcoach-dev/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:taskcoach-dev-digest@... 
    mailto:taskcoach-dev-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    taskcoach-dev-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:

(Continue reading)

Frank Niessink | 21 Aug 21:00

Re: Difficult bug

2008/8/21 Frank Niessink <frank@...>:
> 2008/8/21 Jerome Laheurte <fraca7@...>:
>> No, actually I don't change anything, just click on OK. Maybe there's
>> something you don't do exactly like me, let's detail:
>
> Now I see it too. I'll look into it tonight (when the kids are sleeping 

It's only happening with the trunk, right? I can't reproduce it with
the Release0_70_Branch.

Cheers, Frank

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/taskcoach-dev/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:taskcoach-dev-digest@... 
    mailto:taskcoach-dev-fullfeatured@...

(Continue reading)

Jerome Laheurte | 21 Aug 20:50

Re: Difficult bug

On Thu, 21 Aug 2008, Frank Niessink wrote:

> 2008/8/21 Frank Niessink <frank@...>:
>> 2008/8/21 Jerome Laheurte <fraca7@...>:

>>> No, actually I don't change anything, just click on OK. Maybe there's
>>> something you don't do exactly like me, let's detail:
>>
>> Now I see it too. I'll look into it tonight (when the kids are sleeping 
>
> It's only happening with the trunk, right? I can't reproduce it with
> the Release0_70_Branch.

Indeed. That's because in Release0_70, 
taskcoachlib.patterns.Composite.__getstate__ looks like this:

     def __getstate__(self):
         return dict(children=self.__children[:], parent=self.__parent)

So, no actual copy of children instances, while in trunk it's

     def __getstate__(self):
         return dict(children=[child.copy() for child in 
self.__children],
                     parent=self.__parent)

The children copy is the root of the problem.

Cheers
Jérôme

(Continue reading)

Frank Niessink | 21 Aug 21:25

Re: Difficult bug

2008/8/21 Jerome Laheurte <fraca7@...>:
> Indeed. That's because in Release0_70,
> taskcoachlib.patterns.Composite.__getstate__ looks like this:
>
>     def __getstate__(self):
>         return dict(children=self.__children[:], parent=self.__parent)
>
> So, no actual copy of children instances, while in trunk it's
>
>     def __getstate__(self):
>         return dict(children=[child.copy() for child in
> self.__children],
>                     parent=self.__parent)
>
> The children copy is the root of the problem.

Oops, sorry. I must have been reading the Release0_70_Branch code,
thinking I was reading the trunk.

Cheers, Frank

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

(Continue reading)

Frank Niessink | 21 Aug 21:12

Re: Difficult bug

2008/8/20 Jerome Laheurte <fraca7@...>:
>
> Hi, Frank. I found a bug and I'm at loss as to how to fix it; I see
> several solutions but they may have other impacts...
>
> The bug: Start with an empty file, create a category, then a
> subcategory, then a task. Edit the parent category and click OK. Edit
> the task. The result:
>
>   File
> "/home/jla/WinHome/dev/fraca7/taskcoach-trunk/taskcoachlib/gui/dialog/editor.py",
> line 531, in getCategoryWithIndex
>     category = children[i]
> IndexError: list index out of range
>
> After some digging, I found out that when the category's state is
> saved, patterns.Composite makes a copy of the children. Thus, when the
> edit is undone, the category's children are replaced with copies. But
> the global list of categories keeps the old versions.

I'm not sure your analysis is correct. patterns.Composite does not
copy the children, it only copies the list containing the children:

class Composite(object):
    ...
    def __getstate__(self):
        return dict(children=self.__children[:], parent=self.__parent)

    def __setstate__(self, state):
        self.__parent = state['parent']

(Continue reading)

Jerome Laheurte | 21 Aug 20:54

Re: Difficult bug

On Thu, 21 Aug 2008, Frank Niessink wrote:

> I'm not sure your analysis is correct. patterns.Composite does not
> copy the children, it only copies the list containing the children:
>
> class Composite(object):
>    ...
>    def __getstate__(self):
>        return dict(children=self.__children[:], parent=self.__parent)
>
>    def __setstate__(self, state):
>        self.__parent = state['parent']
>        self.__children = state['children']

See the mail I just sent, in trunk there is an actual deep copy of the 
children :)

> Copying a list this way (l[:]) creates a shallow copy; it's a new
> list, but it contains the same objects. To illustrate:

Actually, I ran trunk for half a day by replacing the

children=[child.copy() for child in self.__children]

with

children=[self.__children[:]]

in Composite.__getstate__. I dind't realize that the copy stuff 
appeared in trunk. But I'm not sure this fix is right, after all there

(Continue reading)

Frank Niessink | 21 Aug 21:41

Re: Difficult bug

2008/8/21 Jerome Laheurte <fraca7@...>:
> Actually, I ran trunk for half a day by replacing the
>
> children=[child.copy() for child in self.__children]
>
> with
>
> children=[self.__children[:]]

Without problems I assume, since you are not mentioning any problems?

> in Composite.__getstate__. I dind't realize that the copy stuff
> appeared in trunk. But I'm not sure this fix is right, after all there
> is probably a reason why you changed the shallow copy for a deep one
> in trunk ? This seems to be part of the 'domain objects may have any
> other domain object as children' change.

I'm not entirely sure, but I may have been trying to have copy() use
__getstate__() because of the duplication between __getstate__() and
copy(). I must have decided that that wasn't really possible but not
changed things back again in good order.

I may have seen this (example from patterns.Composite):
   def copy(self, *args, **kwargs):
        kwargs['parent'] = self.parent()
        kwargs['children'] = [child.copy() for child in self.children()]
        return self.__class__(*args, **kwargs)

and thought to myself: hey, I can use __getstate__ to get the
necessary information and then simply have copy look like this

(Continue reading)

Jerome Laheurte | 21 Aug 21:42

Re: Difficult bug

On Thu, 21 Aug 2008, Frank Niessink wrote:

> 2008/8/21 Jerome Laheurte <fraca7@...>:
>> Actually, I ran trunk for half a day by replacing the
>>
>> children=[child.copy() for child in self.__children]
>>
>> with
>>
>> children=[self.__children[:]]
>
> Without problems I assume, since you are not mentioning any problems?

Indeed, but since I don't use undo very often, it doesn't mean much. I 
just checked that the task editor showed up OK after the category 
editing/undo stuff. There may be side effects when doing more 
complicated stuff.

> I'm not entirely sure, but I may have been trying to have copy() use
> __getstate__() because of the duplication between __getstate__() and
> copy(). I must have decided that that wasn't really possible but not
> changed things back again in good order.
>
> I may have seen this (example from patterns.Composite):
>   def copy(self, *args, **kwargs):
>        kwargs['parent'] = self.parent()
>        kwargs['children'] = [child.copy() for child in self.children()]
>        return self.__class__(*args, **kwargs)
>
> and thought to myself: hey, I can use __getstate__ to get the

(Continue reading)

Frank Niessink | 21 Aug 22:41

Re: Difficult bug

2008/8/21 Jerome Laheurte <fraca7@...>:
> So why not use the standard library 'copy' module, which does just
> that, AFAIK ?

Yeah, that was one option crossing my mind. Then we can implement
__copy__ and __deepcopy__ as needed.

> Mmmh, I'm not keen on adding an extra keyword argument to a special
> method used by the standard library (I think __getstate__ and
> __setstate__ are used by both copy and pickle). There's something that
> bugs me there: a method that is supposed to return a state,
> independent from any application-specific class, actually returns
> something that include instances of domain objects. I think that
> instead of including a list of children copies, it should include a
> list of children states. As I said earlier, this will need special
> handling for deletion/creation of children, but I think it's worth it.

Well, __getstate__/__setstate__ are historical accidents. I think I
used the pickle module when I started with TC. We can rename these
methods any way we want.

Although I agree with your dislike of a method called getstate that
returns a mixture of state and objects, I am not sure that that is the
root issue. I've been thinking for a while now that the whole state
copying is a bad thing. We need to copy the state because of the edit
dialogs. With the current edit dialogs, we don't know what the user is
going to change and she may basically change any property of an
object, including the addition or removal of a whole tree of sub
objects. That's why we need to copy the whole state of domain objects.
Now, if the user cannot edit the whole state of an object, but only

(Continue reading)

Jerome Laheurte | 22 Aug 09:23

Re: Difficult bug

On Thu, 21 Aug 2008, Frank Niessink wrote:

> [snip things I'll answer later]

> However, there's another however: the dialog-less interface is of
> course too much work to fix this bug, so (stop dreaming Frank) we
> still need to fix this bug now. I don't think we should worry too much
> about getstate not being totally consistent, though.

A quick fix: let's replace children=[child.copy() ...] with 
children=self.__children[:]. AFAIK, the only bug this introduces is 
that if someone edits a note belonging to a task or category and 
cancels the task/category editing, the note is still modified. Minor 
bug compared to this one (After the undo, you not only can't edit 
tasks, but you can't save anything). I'll commit this ASAP.

Cheers
Jérôme
------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/taskcoach-dev/join

(Continue reading)

Jerome Laheurte | 22 Aug 10:46

Re: Difficult bug

On Thu, 21 Aug 2008, Frank Niessink wrote:

> 2008/8/21 Jerome Laheurte <fraca7@...>:
>> So why not use the standard library 'copy' module, which does just
>> that, AFAIK ?
>
> Yeah, that was one option crossing my mind. Then we can implement
> __copy__ and __deepcopy__ as needed.
>
>> Mmmh, I'm not keen on adding an extra keyword argument to a special
>> method used by the standard library (I think __getstate__ and
>> __setstate__ are used by both copy and pickle). There's something that
>> bugs me there: a method that is supposed to return a state,
>> independent from any application-specific class, actually returns
>> something that include instances of domain objects. I think that
>> instead of including a list of children copies, it should include a
>> list of children states. As I said earlier, this will need special
>> handling for deletion/creation of children, but I think it's worth it.
>
> Well, __getstate__/__setstate__ are historical accidents. I think I
> used the pickle module when I started with TC. We can rename these
> methods any way we want.
>
> Although I agree with your dislike of a method called getstate that
> returns a mixture of state and objects, I am not sure that that is the
> root issue. I've been thinking for a while now that the whole state
> copying is a bad thing. We need to copy the state because of the edit
> dialogs. With the current edit dialogs, we don't know what the user is
> going to change and she may basically change any property of an
> object, including the addition or removal of a whole tree of sub

(Continue reading)

Frank Niessink | 22 Aug 20:18

Re: Difficult bug

2008/8/22 Jerome Laheurte <fraca7@...>:
> Actually, the copy stuff works well for 'real' composite objects, when
> children are actually 'part' of the parent in a 1:n relationship,
> which is not the case with categories. For notes belonging to a task,
> it doesn't cause any problem. Though the fact that the __id is changed
> bugs me (it will cause problems with the synchronization framework,
> for instance).

The id should *not* be changed when getting or setting the state, but
the id *should* be changed when creating a copy. If I mixed that up
than that's a bug.

> * The bug is fixed
> * We can provide a 'local' undo/redo mechanism in the editor dialog
> * We can add functionnality (for instance, edition of categories from
> within the task/note editor) and it will just work (nested dialogs
> scenario described earlier)
> * We can factorize some code by using, for instance, an actual
> CategoryViewer in the task/note/... editor.

Yes, this does sound attractive. However, please give me a couple of
hours to cleanly separate copy/getstate. The trunk has two failing
unittests related to that, and I'd like to fix that first. I'll let
you know when that's done.

Cheers, Frank

------------------------------------

Yahoo! Groups Links

(Continue reading)

Jerome Laheurte | 22 Aug 20:19

Re: Difficult bug

On Fri, 22 Aug 2008, Frank Niessink wrote:

> 2008/8/22 Jerome Laheurte <fraca7@...>:

>> Actually, the copy stuff works well for 'real' composite objects, when
>> children are actually 'part' of the parent in a 1:n relationship,
>> which is not the case with categories. For notes belonging to a task,
>> it doesn't cause any problem. Though the fact that the __id is changed
>> bugs me (it will cause problems with the synchronization framework,
>> for instance).
>
> The id should *not* be changed when getting or setting the state, but
> the id *should* be changed when creating a copy. If I mixed that up
> than that's a bug.

Agreed.

>> * The bug is fixed
>> * We can provide a 'local' undo/redo mechanism in the editor dialog
>> * We can add functionnality (for instance, edition of categories from
>> within the task/note editor) and it will just work (nested dialogs
>> scenario described earlier)
>> * We can factorize some code by using, for instance, an actual
>> CategoryViewer in the task/note/... editor.
>
> Yes, this does sound attractive. However, please give me a couple of
> hours to cleanly separate copy/getstate. The trunk has two failing
> unittests related to that, and I'd like to fix that first. I'll let
> you know when that's done.

(Continue reading)

Frank Niessink | 23 Aug 00:02

Re: Difficult bug

2008/8/22 Jerome Laheurte <fraca7@...>:
> I didn't plan on doing anything today anyway :) But I'll have plenty
> of time this week-end, seeing how bad the weather is here in Paris,
> and my friends being on holiday. Just tell me when you're finished and
> I'll start hacking.

I added a __getcopystate__ method that is used for copying instead of
__getstate__. Here's the commit message:

Don't use __getstate__ for getting the contents of a domain object that is
about to be copied, but rather use the new method __getcopystate__. The
difference between the two is that __getstate__ returns a shallow copy of
the state of an object, whereas __getcopystate__ returns a deep copy of
the state. For example, the state returned by __getcopystate__ will
include a copy of the children in case of a composite object, it will include
a copy of attachments and for tasks it will include a copy of effort
records. It will not, however, return a copy of the categories that an
object ('categorizable') belongs to, since categories don't have to be
copied when copying a categorizable.

I focused on getting the copying right, but didn't look into the
undo/redo stuff. I'll leave that to you 

cheers, Frank

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:

(Continue reading)

Jerome Laheurte | 23 Aug 12:52

Re: Difficult bug

On Sat, 23 Aug 2008, Frank Niessink wrote:

> I focused on getting the copying right, but didn't look into the
> undo/redo stuff. I'll leave that to you 

Done, seems to work well. It's nice to be able to create a category 
from within the task/note editor :)

In other news, I'd like to add a 'contrib' directory to store stuff 
related to TaskCoach but not exactly part of it. I already have a 
script that uses Python bindings for coldsync in order to synchronize 
with a Palm, which would be better there. Also, I upgraded the 
'taskcoach' tool for Faces (http://faces.homeip.net/) and submitted a 
patch, but the project doesn't seem to be very active and I think this 
tool would be better in TaskCoach SVN anyway.

No objection ?

Cheers
Jérôme
------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

(Continue reading)

Frank Niessink | 23 Aug 17:27

Re: Difficult bug

2008/8/23 Jerome Laheurte <fraca7@...>:
> On Sat, 23 Aug 2008, Frank Niessink wrote:
>
>> I focused on getting the copying right, but didn't look into the
>> undo/redo stuff. I'll leave that to you 
>
> Done, seems to work well. It's nice to be able to create a category
> from within the task/note editor :)

Great, I'll take a look.

> In other news, I'd like to add a 'contrib' directory to store stuff
> related to TaskCoach but not exactly part of it. I already have a
> script that uses Python bindings for coldsync in order to synchronize
> with a Palm, which would be better there. Also, I upgraded the
> 'taskcoach' tool for Faces (http://faces.homeip.net/) and submitted a
> patch, but the project doesn't seem to be very active and I think this
> tool would be better in TaskCoach SVN anyway.

Would that be /svnroot/taskcoach/trunk/contrib or
/svnroot/taskcoach/trunk/taskcoach/contrib? I guess the first option
since that wouldn't clutter regular workspaces? Maybe the rule should
be to put stuff that must/can be released as part of TC in
/svnroot/taskcoach/trunk/taskcoach and stuff that is not released as
part of TC in /svnroot/taskcoach/trunk/contrib.

Cheers, Frank

------------------------------------

(Continue reading)

Jerome Laheurte | 23 Aug 17:17

Re: Difficult bug

On Sat, 23 Aug 2008, Frank Niessink wrote:

> 2008/8/23 Jerome Laheurte <fraca7@...>:
>> On Sat, 23 Aug 2008, Frank Niessink wrote:
>>
>>> I focused on getting the copying right, but didn't look into the
>>> undo/redo stuff. I'll leave that to you 
>>
>> Done, seems to work well. It's nice to be able to create a category
>> from within the task/note editor :)
>
> Great, I'll take a look.
>
>> In other news, I'd like to add a 'contrib' directory to store stuff
>> related to TaskCoach but not exactly part of it. I already have a
>> script that uses Python bindings for coldsync in order to synchronize
>> with a Palm, which would be better there. Also, I upgraded the
>> 'taskcoach' tool for Faces (http://faces.homeip.net/) and submitted a
>> patch, but the project doesn't seem to be very active and I think this
>> tool would be better in TaskCoach SVN anyway.
>
> Would that be /svnroot/taskcoach/trunk/contrib or
> /svnroot/taskcoach/trunk/taskcoach/contrib? I guess the first option
> since that wouldn't clutter regular workspaces? Maybe the rule should
> be to put stuff that must/can be released as part of TC in
> /svnroot/taskcoach/trunk/taskcoach and stuff that is not released as
> part of TC in /svnroot/taskcoach/trunk/contrib.

Agreed. I'll create the folder after I'm done with the attachment 
branch. In case you didn't see the commit messages yet, I'm making the

(Continue reading)

Frank Niessink | 23 Aug 22:30

Re: Difficult bug

2008/8/23 Jerome Laheurte <fraca7@...>:
> Agreed. I'll create the folder after I'm done with the attachment
> branch. In case you didn't see the commit messages yet, I'm making the
> attachments "regular" domain objects, with categories and notes, and
> a dedicated viewer. The only thing that bugs me is that
> "subattachment" isn't a nice word, I think I'll go with 'child
> attachment' :)

You mean you want to make attachments composite? Does that make sense?
Why not make it a non-composite domain object, like effort?

Cheers, Frank

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/taskcoach-dev/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:taskcoach-dev-digest@... 
    mailto:taskcoach-dev-fullfeatured@...

(Continue reading)

Jerome Laheurte | 24 Aug 08:21

Re: Difficult bug

On Sat, 23 Aug 2008, Frank Niessink wrote:

> 2008/8/23 Jerome Laheurte <fraca7@...>:
>> Agreed. I'll create the folder after I'm done with the attachment
>> branch. In case you didn't see the commit messages yet, I'm making the
>> attachments "regular" domain objects, with categories and notes, and
>> a dedicated viewer. The only thing that bugs me is that
>> "subattachment" isn't a nice word, I think I'll go with 'child
>> attachment' :)
>
> You mean you want to make attachments composite? Does that make sense?
> Why not make it a non-composite domain object, like effort?

Though I agree children attachment are sometwhat strange, I'd really 
like to have notes in attachments.

Cheers
Jérôme
------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/taskcoach-dev/join

(Continue reading)

Jerome Laheurte | 24 Aug 08:37

Re: Difficult bug

On Sun, 24 Aug 2008, Jerome Laheurte wrote:

> On Sat, 23 Aug 2008, Frank Niessink wrote:
>
>> You mean you want to make attachments composite? Does that make sense?
>> Why not make it a non-composite domain object, like effort?
>
> Though I agree children attachment are sometwhat strange, I'd really
> like to have notes in attachments.

And now I realize a NoteOwner is not necessarily composite.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/taskcoach-dev/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:taskcoach-dev-digest@... 
    mailto:taskcoach-dev-fullfeatured@...

(Continue reading)

Frank Niessink | 24 Aug 20:33

Re: Difficult bug

2008/8/24 Jerome Laheurte <fraca7@...>:
> On Sun, 24 Aug 2008, Jerome Laheurte wrote:
>
>> On Sat, 23 Aug 2008, Frank Niessink wrote:
>>
>>> You mean you want to make attachments composite? Does that make sense?
>>> Why not make it a non-composite domain object, like effort?
>>
>> Though I agree children attachment are sometwhat strange, I'd really
>> like to have notes in attachments.
>
> And now I realize a NoteOwner is not necessarily composite.

Yay, best of both worlds 

Cheers, Frank

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/taskcoach-dev/join
    (Yahoo! ID required)

(Continue reading)

Return

Return to gmane.comp.sysutils.pim.taskcoach.devel.

Advertisement

Project Web Page

Discussion list for developers of the Open Source (GPL) task manager software Task Coach

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane