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
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
[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. 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. 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] Multiple child-addressbooks under an account
On Sun, 2011-01-23 at 01:26 +, Kirk Wolff wrote: > On Sat, 2011-01-22 at 14:23 -0500, Adam Tauno Williams wrote: > > On Fri, 2011-01-21 at 19:49 +0100, Onyeibo Oku wrote: > > > On 01/21/2011 06:30 PM, Kirk Wolff wrote: > > > > Is there a way to add child-addressbooks under an addressbook account > > > > with evolution's GUI? I don't see any current implementations that have > > > > a 'tree' of addressbooks under an addressbook plugin type. As I see it, > > > > there are plugins for setting up an addressbook, but not for displaying > > > > and organizing them. It seems the presentation (the left-hand column > > > > list) of addressbooks is fixed. Is there a simple way to add and > > > > maintain a tree in the list of addressbooks? > > > I don't see any special benefit for this feature. > > The use case seems *obvious* to be; especially for WebDAV address books > > since WebDAV supports hierarchical collections [although > > CalDAV/CardDAV/GroupDAV all place restrictions on how child collections > > can be structured]. > > If you have multiple server-side collections of contacts you currently > > have to define multiple addressbooks rather than just one that can > > expand to list the collections - even supporting descending a single > > level of collections would be *very* useful. > I agree, from the CardDAV spec, its natural to want to show all of the > available addressbooks with a single sign-on, especially if the spec > supports it. > My primary question here is not whether it should be done, but how to > do it from within a plugin. > I presume from your response that its currently not possible but may > be possible if a plugin is written to allow it. I'd almost swear that at some point in the last 10+ years I've seen an addressbook-tree; but it certainly doesn't happen currently. > Can anyone provide some direction as to how to write this plugin? Sadly I can't be of any help there. Perhaps looking at code in the Exchange or Groupwise plugins might tell you something. ___ 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] 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
