Re: [Evolution-hackers] [Draft] Evolution Road-map for post-3.12
Here's my list. There's a few items on the wiki page I've been dragging along for a few releases now. Those are still on my agenda, even the importer rewrite. https://wiki.gnome.org/Apps/Evolution/Planning310 Additionally I want to really focus on getting Camel's API fixed up well enough to split off from E-D-S and declare stable. I've intended to do that for several years [1], but parts of Camel's API are still a mess and I'm not yet willing to commit to them. Among the things that need done yet are: * Kill CamelStream and all its subclasses and port Camel entirely to GIO-based streams. I'm already making some headway on that. * Move all the filtering logic into Evolution. Camel's filtering logic is already highly dependent on Evolution and not fleshed out well enough to be usable on its own. From there I can more easily make some badly needed improvements under Evolution's umbrella, where API stability isn't an issue. * GMime is Jeff Steadfast's partial fork of Camel, and there's still a lot of shared heritage there. I understand he added a pretty comprehensive test suite, and I'd like to try importing that and adapting it to Camel's current APIs. * Study/cleanup/document the summary database and virtual folders. I still don't really have my head around these areas. The APIs are a mess and nothing's documented. I'd like to spend a little time on it and probably do some refactoring before the split, because I can't maintain this stuff if I don't understand it. * Maybe annotate the API for introspection and generate language bindings? Even if there's no demand for Camel bindings, I think the practice helps promote good discipline and API design and is worth the effort. Between the wiki page items, this stuff, and the usual caring and feeding of the project, I think that's a pretty full plate for me. Matt [1] https://mail.gnome.org/archives/evolution-hackers/2009-November/msg00019.html ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Draft] Evolution Road-map for post-3.12
Hello, as all/most of you might know, after 3.12 release Evolution changes its release schedule to a yearly development, which may give more room for any larger changes. I'd like to start a Road-map draft with things I believe will be good to have. They are not in any particular order, any of them can be moved up/down/dropped/... Probably not all of them will make it for 3.14, but that's understandable. Here's the list: * complete the Webkit-based composer - either complete or just take care of bugs from users - fixes might reach 3.12 as well * revisit the webkit2 port * change the UI of component editors for calendar views (events/tasks/memos) * merge calendar views internally - to avoid code duplication; after all, the main differences are only a) component type; b) allowed subviews (day/month/.../list). Otherwise they are just the same. It'll be a big task, because I'd like, together with it, avoid UI thread blocking from calendar-related views * renew the calendar views to gtk-based or webkitwebview based views * add an offline cache for calendar and book backends, together with: * create a meta backend, which will allow backend writers to focus on the tasks related to conversion from libical components into their stores, instead of reimplementing common things; this task might depend on the offline cache, because it would be nice to have the meta backend with the offline support built-in, thus the users of the meta backend gets something more for free * merge backend factory codes even more than it is now, because the book and calendar factories are basically the same, serving to the same thing, thus there surely is more common things that can be done in one place, not two * make backend factories crash-proof - a thing which I think Matthew suggested (a long) time ago - move each backend to a separate process, thus if any of them crashes for whatever reason, the other backends will keep running (all backends are running in one process today, thus when one crashes, all of them are gone too) I cannot recall anything more right now, sadly neither for EWS, but there are surely some nice feature requests, which would be nice to have done (like the Information Rights Management thing). Please add things you would like to have, or do not like to have, or comment on any of them. This is only a draft, after all. Thanks and bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Draft] Evolution Road-map for post-3.12
On Thu, Jan 23, 2014 at 5:12 PM, Milan Crha mc...@redhat.com wrote: Hello, as all/most of you might know, after 3.12 release Evolution changes its release schedule to a yearly development, which may give more room for any larger changes. I'd like to start a Road-map draft with things I believe will be good to have. They are not in any particular order, any of them can be moved up/down/dropped/... Probably not all of them will make it for 3.14, but that's understandable. Here's the list: * complete the Webkit-based composer - either complete or just take care of bugs from users - fixes might reach 3.12 as well * revisit the webkit2 port * change the UI of component editors for calendar views (events/tasks/memos) * merge calendar views internally - to avoid code duplication; after all, the main differences are only a) component type; b) allowed subviews (day/month/.../list). Otherwise they are just the same. It'll be a big task, because I'd like, together with it, avoid UI thread blocking from calendar-related views * renew the calendar views to gtk-based or webkitwebview based views * add an offline cache for calendar and book backends, together with: * create a meta backend, which will allow backend writers to focus on the tasks related to conversion from libical components into their stores, instead of reimplementing common things; this task might depend on the offline cache, because it would be nice to have the meta backend with the offline support built-in, thus the users of the meta backend gets something more for free * merge backend factory codes even more than it is now, because the book and calendar factories are basically the same, serving to the same thing, thus there surely is more common things that can be done in one place, not two * make backend factories crash-proof - a thing which I think Matthew suggested (a long) time ago - move each backend to a separate process, thus if any of them crashes for whatever reason, the other backends will keep running (all backends are running in one process today, thus when one crashes, all of them are gone too) I cannot recall anything more right now, sadly neither for EWS, but there are surely some nice feature requests, which would be nice to have done (like the Information Rights Management thing). I'd like to revisit this thread[0] at some point in the future. [0]: https://mail.gnome.org/archives/evolution-hackers/2013-May/msg3.html Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
