Evo Future
From Evolution
This section shows tasks that cannot be done in time for the next stable release, but that are really needed, either because users demand them or because they are needed for the future evolution of the software.
Contents |
Bonobo-free Evolution
It's high time Evolution dumped its Bonobo dependency once and for all. I've chipped away at the edges for the past year (New_Composer, CompEditor), but I'm now working toward delivering the fatal blow in a branch called "kill-bonobo". This will involve basically a rewrite of the shell to use GTypeModule for components and lots and lots of migration of menus, toolbars, and plugins to GtkUIManager and EPluginUI. GNOME 2.26 is the target. [mbarnes, 07/2008]
Kolab2 Support
Include support for some of the advanced features of kolab2. Or even start with options for been able to select Kolab2 as a server type, and be prompted for server address etc etc.
API
Simplified date management
The calendar API uses a few different date/time types, which make the API look much more complicated than what it should be.
Right now, we are using time_t, struct icaltimetype, from libical, and ECalComponentDateTime. Also, neither of these support other calendars official in some countries (like Hebrew, Islamic, and Persian) than the gregorian one, which makes it hard for users in those countries that don't use the gregorian calendar.
We need then to have a unique date/time type that does not have the limitations of some of the types we use now (time_t only works, for instance, from 1970 to 2037) and that supports other calendars. This type could be GLib's GDate/GTime, but after adding to them several things, like timezone information, which we require, and other kinds of calendars. There is a bug about it, opened by Roozbeh (see here) which could be used as a tracking bug for the task.
[NotZed] a 64 bit time_t goes a lot further than 2038.
libical replacement
libical, the library used for parsing iCalendar components, needs to be replaced by a better one. Ideally, we would make ECalComponent be the parser itself, thus removing all the libical types that are used in it.
Update: The upstream libical project is active again, so we're looking at merging changes to our fork with upstream. [mbarnes, 07/2008]
Another option, to at least have a much better API, would be to remove all public use of libical types from ECalComponent and other libecal API. Thus, it would make it easier to do C# (and other languages) bindings and it would make a much better API.
Async client APIs for calendar in EDS
We have to implement asynchronous client side apis for calendar and use them in evolution. This would solve much of the hang related issues in calendar.
[NotZed] Umm, actually I think the backend needs fixing to use a synchronous api first. Otherwise having an async layer ontop of an async layer will fail to ever work.
Modular View Control
As of now each calendar view uses a seperate model. We need to have a single model for all views. The data must be stored in the model and views must be reference to objects from the model instead of having duplicates which would reduce memory buildups to some extent.
Calendar/Tasks editors move to E-D-S
Right now, the calendar and tasks editors are internal to Evolution, and can only be used there or though ugly CORBA calls, which nobody has used for years. So, the best solution seems to be to move them to E-D-S (libedataserverui) and make them available for everyone to use them, like the clock applet or any other application using E-D-S for calendar/tasks.
Update: As of 2.23, the editors are now GtkWindow subclasses and the CORBA gunk is gone. Moving these to libedataserverui may be more viable now, although it needs a lot more refactoring before we commit to an API. [mbarnes, 07/2008]
We tried to do this for 2.2, but we found out a dependency on the mail composer, which prevented the move to happen, since it involved moving lots of the mailer code also.
The code to be moved is mostly in the calendar/gui/dialogs directory, and includes the following files:
- alarm-dialog.[ch] implements the dialog for setting a custom alarm for an event. This does not need to be public API, and can be kept internal.
- alarm-list-dialog.[ch] implements the dialog that shows the list of alarms that have been set in the event.
- cal-attachment-bar.[ch], cal-attachment-select-file.[ch] and cal-attachment.[ch] implement the management of the attachments bar. This do not need to be public API.
- comp-editor-page.[ch] implements the base class for both calendar and tasks editor pages.
- comp-editor.[ch] implements the base class for both calendar and tasks editors.
- event-editor.[ch] implements the event editor.
- event-page.[ch] implements the event editor page.
- meeting-page.[ch] implements the meeting page.
- recurrence-page.[ch] implements the recurrence page.
- schedule-page.[ch] implements the schedule page.
- task-details-page.[ch] implements the task details page.
- task-editor.[ch] implements the task editor.
- task-page.[ch] implements the task editor page.
Apart from those, there are some dependencies on the dialogs that are shown for various operations within the editors. These should probably also be moved, but maybe it is not a good idea to have them as part of the public API. The problem with that is that Evolution itself uses those dialogs, so they need to be available for Evolution also.
About the composer dependency, so far the best solution seems to be to define EPlugin hooks for the editors, so that Evolution can provide these hooks to make the editors use the composer. Other applications would have to the same, or reuse the Evolution composer, if possible.
User Interface
New calendar view widget
The way calendar views are now done makes it difficult to: have full accessibility support, improve the look & feel to make it much better than other similar applications, maintain it, since a lot of code is duplicated.
Some ideas have come up about what to do with them, the best of which, so far, seems to be to write a unique view widget that can show information in different ways. This will avoid having to duplicate so much code.
Another option is to leave them as they are (EDayView, EWeekView and ECalListView) but make all the drawing be shared. In fact, the drawing of the events is mostly the same (with small differences) for all views (except list view, which is the simplest one), so we could make the views draw the days/months, and have all the drawing of the events be shared for both views.
GtkHTML and GtkMozembed
Replacing gtkhtml with something like gtkmozembed would be, from a maintenance standpoint, great. We'd lose a lot of flexibility around trapping clicks and object tags and probably more though. gtkmozembed also does not expose any editing capabilities so we'd have to write our own wrapper anyhow. GtkHTML might mostly "done" other than CSS and bugs now, since it now includes RTL, a11y and IM support.
Thoughts and ideas to replace gtkhtml with gtkmozembed
Update: I think we're pretty well settled on moving to WebKit/GTK+, as soon as it grows a GObject-based editing API. [mbarnes, 07/2008]
Evolution Sync with handheld devices
GNOME pilot
Provision for syncing multiple calenders with my pilot. This is a request from Carl Davis <>. I have my local calendar file that has personal stuff in it. And I have a webdav calendar that has Office stuff in it. I would like to have all events in my pilot. Right now I have to manually copy to get my palm to get both personal and corportate meeting details.
Multisync
See http://www.multisync.org. We must evaluate the existing Multisync-Evolution plugins hosted on the multisync site first with different handheld devices from pilots to latest mobile phones (like Nokia 6670 and 6680). The evaluation would also require checking of feature parity w.r.t gnome-pilot. See http://sourceforge.net/projects/evolution-memos, it has syncing up PDA memos with evolution using gnome-pilot. Moving to Multisync will have impact on this project, so they need to be taken into confidence. Looks like the development of multisync has moved to http://www.opensync.org.
I have an idea about providing synchronization services as a desktop component on GNOME, just the same way KDE 4 is doing. So if we can avoid implementing all the stuff inside evolution, just the necessary support to communicate with that software. I'm looking at http://www.conduit-project.org, it is not based on opensync actually, but it aims to support it on the future.
Filtering Syncronization and Exporting
Sometimes we use Evolution on several computers, and it could be useful to have a good way to syncronize filters between them. Actually, copying filters.xml file does not work because of the way evolution gives names to folders, so you have to use sed or any other tool to reuse them on another computer.
- Make filters and virtual forders not depend on local machine-specific data.
- Import and export filters, and be able to store them on a server on Internet, via FTP, WebDAV, etc. or just take them in a usb keychain to another computer and drag and drop on evolution to copy that filters.
- Syncronize filters between computers: For example between a laptop, home PC and office PC so when you change a filter on one of them, the others can update the new rules.
