[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
