Re: [Evolution-hackers] Multiple child-addressbooks under an account
On Sat, 2011-01-22 at 14:23 -0500, Adam Tauno Williams wrote: This really seems like a server-side issue to me. The issue really is there is no way standard way to specify a hierarchy of tasks in either UI or in the representation [VTODO] so I think that would be a special/custom plugin. I was under the impression that VTODO did support parent/child/sibling relationships. Like: http://tools.ietf.org/html/rfc5545.html#section-3.8.4.5 Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN All is fear in love and war. signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Hierarchical Tasks [Was: Multiple child-addressbooks under an account]
Please use Ctrl-L [reply-to-list] rather than Reply-All when replying to list messages. On Sun, 2011-01-23 at 15:50 +1000, Andrew McMillan wrote: On Sat, 2011-01-22 at 14:23 -0500, Adam Tauno Williams wrote: This really seems like a server-side issue to me. The issue really is there is no way standard way to specify a hierarchy of tasks in either UI or in the representation [VTODO] so I think that would be a special/custom plugin. I was under the impression that VTODO did support parent/child/sibling relationships. Like: http://tools.ietf.org/html/rfc5545.html#section-3.8.4.5 It supports relationships, but no specific impact (side-effects) of relationships. QUOTE Changes to a calendar component referenced by this property can have an implicit impact on the related calendar component. For example, if a group event changes its start or end date or time, then the related, dependent events will need to have their start and end dates changed in a corresponding way. Similarly, if a PARENT calendar component is cancelled or deleted, then there is an implied impact to the related CHILD calendar components. This property is intended only to provide information on the relationship of calendar components. It is up to the target calendar system to maintain any property implications of this relationship. /QUOTE The real-world up-shot of that is that no one will do anything with the attribute described. It would be fantastically useful - the server I work on supports task hierarchies, but to make use of them you need to write 'native' code and your own UI, for VTODO's you are best of just hiding that aspect of the data model (and I've never seen a client that supported it in any capacity). You'll also run into consistency issues when using GroupDAV/CalDAV/CardDAV and the server tries to be 'helpful' or smart. For example if on a CalDAV server I have a todo list of many tasks and three of those tasks are linked in some way - the client makes a modification to one of those tasks which has a side-effect on the status of the two other tasks the client will remain merrily oblivious to that fact that the other objects in the collection have changed. This is just a crappy part of the specs, there isn't any widely supported mechanism for the server to notify the client that certain references in its cache have been invalidated. The only way the client figures that out is if it polls the collection; which can be slow and/or computationally expensive. Polling the entire collection after every update would just be brutal - but it is the only way to remain consistent. So your proposed feature of the completion of child tasks bumping the percent complete of the parent task would be frustrating for the user because the user would not see the percentage of completion of the parent task change. And what if they then open the parent task and manually set the percentage complete? You now have a conflicting update. Beyond that there is the issue that if the parent task has four children, and three are complete - so the percent complete is 75% - and the user adds a fifth child task does the percent complete now decrease to 60%? What if each of the child tasks is not a proportional section of the parent task? Do you let the user specify each sub-total of work? There certainly is no standard attribute for that so you are down to using an X- attribute that risks getting discarded by badly behaving servers and clients. And of course that would require a customized UI to be of any value to the user. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Hierarchical Tasks [Was: Multiple child-addressbooks under an account]
On Sun, 2011-01-23 at 16:51 -0500, Adam Tauno Williams wrote: You'll also run into consistency issues when using GroupDAV/CalDAV/CardDAV and the server tries to be 'helpful' or smart. For example if on a CalDAV server I have a todo list of many tasks and three of those tasks are linked in some way - the client makes a modification to one of those tasks which has a side-effect on the status of the two other tasks the client will remain merrily oblivious to that fact that the other objects in the collection have changed. This is just a crappy part of the specs, there isn't any widely supported mechanism for the server to notify the client that certain references in its cache have been invalidated. The only way the client figures that out is if it polls the collection; which can be slow and/or computationally expensive. Polling the entire collection after every update would just be brutal - but it is the only way to remain consistent. ... Hi, there could be done, as the first step, a hierarchical view of components based on the Andrew's property, and it can do nothing, as a starter, with respect of implicit impact on related components, keeping all this on a user (call it a very simple target calendar system). So Evolution would use it only for viewing. Because the RFC doesn't dictate whether client or server should do implicit impact changes, then the rest can be safely done on the Evolution side (which avoids update issues you mentioned) by some kind of plugin, rather than making evolution's UI too complex. Of course, it might not work with every server, but this kind of issue is there every time. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rebasing gtk3 branches
On Sat, 2011-01-22 at 14:01 -0500, Matthew Barnes wrote: Would anyone mind if I do another round of gtk3 rebases? Hi, what about wait till Wednesday, after evolution team meeting, and then merge gtk3 branches to master branches, and require gtk3 for the Monday 2.91.6 release? It saves a bit of work for you, and also forces people to fix new issues related to gtk3, both during Thursday and Friday, and also benefit from more testers with 2.91.6 release. This might be doable, especially because: ... and it's quite usable. A few minor glitches left but canvas widgets now draw and scroll correctly, and I'm seeing a few but not an enormous number of runtime warnings on the terminal. which can be fixed till the meeting. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
