Home | Content | Search | Navigation | Personal tools | Actions

Evo2.6

From Evolution

This is the planning page for Evolution 2.6.

I am seeding the page with some initial thoughts and moving stuff from the Future Release Planning page. As always, your comments and contributions are welcome.

--Harish


Contents

[edit]

Hula support including CALDAV

Evolution 2.6 should be a complete Hula Client with tested support for all the features provided by the server.

[edit]

UI Enhancements

UI Improvements ideas are maintained at UI2.6

[edit]

Speed & Memory Improvements

User::bugreports I feel that memory requirements and speed are still A BIG ISSUE.

  • For example clicking on the calendar still one has to wait for 8-10 seconds (!) for something to popup. Scrolling in the calendar is not possible as it takes 2-5 seconds for a refresh.
  • The addressbook show as address cards still takes >20 seconds to display, >10 when scrolling.
  • The standard IMAP takes up to 1 minute to sync although all folders are marked to be offline folders and the messages are there.
  • User:wasabi There should be support for some sort of super minimal memory situation in EDS, with No Client Side Caching! For example, my mail box has over 400 MB of items in it. Old mail, archives, stuff I need to do my job. E-D-S should be functional in low memory environments, such as the Nokia 770, so this needs to be considered at least. It would make sense if only headers were cached in memory, and freed when no clients need them, for this device size.
  • IMAP when going online also seems to touch each header creating a lot of network traffic.
  • evolution/e-d-s often eat up several hundred megabyte, so full valgrind runs to fix these memory leaks should be done.
[edit]

Polish up EDS APIs

Achieve a stable, documented, extensible set of APIs that will position us for proposing evolution-data-server to the GNOME platform.

[1] Required changes in calendar - movement of editors, libical replacement.

A how-to guide on developing against EDS Calendar APIs and a design doc is in the pipeline..Should be out for review soon...Harish

User:notzed Are there any plans then to fix the horrendous corba and wrapper layers used by the backends? The sync gobject->async bonoboobject->sync gobject->wrapper gobject->layer implementation->data stuff is never going to be a good solution.

user:vseguip Adding SWIG interface files would be nice to ease the creation of bindings for different languages like the current C# or Ruby ones. This way writing small desktop utilities could be very easy (think of Karamba/GDesklet/panel applets, etc). I'm willing to start the effort and help from anybody will be greatly appreciated.

This is being discussed further in SWIGforEDS -Harish

[edit]

Explore DBUS based Addressbook

  • Profile Ross' patch for libebook and match it against the current implementation.
  • Integration with the current libebook module and API

user:notzed we can't even get a single super-trivial event notification running with d-bus, i find this suggestion somewhat bizarre. user:RossBurton That's a bug in the eplugin. I've been using the dbus port of libebook for months now

[edit]

Camel/Mailer

  • Accessing mails through EDS:

User:sparthasarathi This looks a little far-fetched currently. But hopefully looking at a branch with work on 'moving' the entire mail functionality to EDS.

Some notes on this are available in the mail in EDS page.
  • On-Disk Summaries:

User:sparthasarathi NotZed has a disk-summaries branch which he is working on already. And it looks pretty interesting. 2.6 from mailer would be lesser memory foot-print thanks to disk-summaries. There was a wiki page by Michael on this, which i could not find. Would update once i do.

Some initial notes on this are discussed on the on-disk summaries page, however the code has moved on from there a bit, so an update will be forthcoming; more in line with a handover document.

User:poornima Summary information of messages in default folders of groupwise account should be downloaded as soon as user logs in. At present when user clicks on 'Inbox', evolution starts fetching summary information of all mails in 'Inbox'. Simillarly for other mail folders like 'Sent Items', 'Trash'. Bugzilla entry to track this requirement #316144

  • Auto-Reply and Auto-Forwarding on Filters:

It would be great to have this in 2.6. -Harish

  • Support for public folders in the IMAP backend

This is something for which some users prefer IMAP4rev1. -Harish

  • Support for the "idle" extension in the IMAP backend

This would allow for real time notification and reception of incoming emails, without the need to keep polling the email server (as already available in thunderbird or gnome notification applet)

  • User:bugreports A shortcut navigate through new mail even accross different folders of the same account, should be #302997
[edit]

Unified Account Management

Information pertaining to groupware accounts (that provide mail, calendaring and addressbook) is split into EAccounts and multiple ESources, making them difficult to manage. User data is also spread over .evolution and .gconf. This needs to be consolidated into a more manageable format.

This also means the awful e-sources api has to go away completely, the calendar and addressbook eds services need to be re-arranged into a more appropriate session/store architecture, e-account needs to be redesigned, and the mail account editor needs to be completely scrapped and converted into a global account editor. While we're at it, no account information should be stored in gconf anymore.
User:Andre: carefully check that removing account information is not a contradiction to adding dave's Evolution Gconf tools to evolution (see Evo2.6#Misc).

User:Surf Any particular reason why we would want to drop off storing information in gconf here ? And what would be the alternative for this ?


User:lukescott: how can anyone even ask that question - the fact is, storing information in two places (one place has the data, the other place has the metadata) is completely against the philosophy of streamlined data storage. One folder should apply to one application. There are some settings that could be appropriate to keep in gconf (basic settings like window & panel sizes, what day the week starts on, etc) but IN NO WAY should it EVER be possible to LOSE DATA by having two UNRELATED DIRECTORIES out of sync (.evolution, .gconf). Unrelated directories should be free to be deleted and recreated without any effect on the other. To have such a situation is simply a design flaw. As for contradictions with Dave's GConf tools, no design decisions should be made with a previous band-aid solution being considered set in stone. Band-aids are temporary fixes for dealing with design flaws and should be discarded whenever appropriate. I haven't used his tools but if any of them "fix" this user-data-in-gconf problem, then those parts of the tool set should be discarded.

[edit]

Notes/Memos component and support for GW Reminder Notes

  • Nathan Owens' patch has been approved and would be committed as soon as we branch out evolution-2.4 from the HEAD.

Support for Hula and GroupWise servers.

[edit]

Groupwise support

We can add the following features

  • Retracting emails and meetings.
  • Resending the meeting requests.
[edit]

Moving editors to EDS

See the following link for more info Moving editors to EDS

[edit]

Calendar publishing

There are two patches in the patches list for calendar publishing

[edit]

Web calendar support

Adding support to access authenticated web calendars and enable to save the changes to the same.

[edit]

Offline write support for calendar

Adding support for making the changes in offline mode for web, groupwise, exchange calendars etc.

[edit]

Enhancing Evolution Alarm Notifier

Please update your views on the points presented about enhancing Evolution's Alarm Notifier here.

  • After creating a "run a program" alarm in Calendar, one cannot go back in and view/change the details of the alarm.
  • "run a program" alarm should have macros to insert parts of the Calendar entry as arguments to the user-supplied program. For example, Program file=/my/bin/sendpage :: Program args=%S %L %D # %S = "Summary", %L = "Location", %D = "Description" from the event's "Basics" info.
[edit]

Refreshing calendars

Add support for refreshing all calendars and a specific calendar. We can use the existing send/receive button to trigger the refresh for all calendars and add right click menu on the source group to refresh specific calendars. Currently we can specify refresh time interval for web calendars only. This can be added to groupwise and web calendars also.

  • Web calendars I have imported into Evolution show this behavior: entries are visible for one refresh cycle, then disappear. Exiting and restarting Evolution is the only way I have found to get them to reappear.
[edit]

Offline write support for address books

Adding suppfort for making the changes in offline mode for LDAP, groupwise, and exchange address books.

[edit]

Better importers for address books

We should support thunderbird ldif files. Fix all the problems with the current vcf and ldif importers.

Currently we support only vcard and ldif importers. We should also be supporting csv and tab formats as this gives more options for somebody moving from some other mail client to evolution.

User:Andre: see bug 258920 (although it's about exporting).

[edit]

Autocompletion and name selector dialog related changes

Currently autocompletion just shows the names and e-mail ids. This is the problem when a contact has multiple ids and user wants to know the e-mail id picked up during autocompletion or likes to use some other e-mail id. the right click menu just lists the e-mail ids and there is no clear way of knowing these details. See #272391, #231751


Also in the case of contact lists,

  • When the name selector dialog is invoked from CC or BCC filed, double click on an adderess should add the selected address to "CC" or "BCC" filed and not always to the "To" filed.
[edit]

LDAP address book enhancements

[edit]

Usability and UI Issues with address book

  • A folder menu is needed for address book also. This can have options to create/delete/rename folders and also edit folder properties, select all the contacts, save all contacts etc. Right now the only way of doing some of these operations in using the right click menu.
  • Allow selection of multiple categories while searching. See #228861 (wrong bug number ?)
  • Category selection needs to be improved:
    • Autocompletion, when typing in the field in Contact Editor
    • better selector Dialog, where all categories can be seen at once (not necessary to scroll)
    • select multiple contacts and add them to a certain category
  • The master category list should be sorted alphabetically
  • Adding Tags to contacts would be a great feature, as in f-spot for pictures.
    • you don't need mailling list anymore, you can select a particular tag or even combine tags with OR, AND operators.
    • you can add tags to contacts more easily than modifying a mailling list.
    • It is easyier to have a contact tagged 'friend' and 'work', and so on.
    • Browsing through the address book becomes easyier too.
[edit]

Handhelds support

  • Evaluate Opensync and the evolution plugin available there.
  • Feature parity check should be done between gnome-pilot and opensync
  • Provide a unified interface to gnome-pilot and opensync (may be till opensync is completely adopted by the gnome community)
  • User::bugreports It might be even worth dropping support for gnome-pilot and only use opensync.
[edit]

Misc

Suggestions by TorLillqvist:

  • Clean up duplicated functionality in e-d-s's libedataserver, evolution's e-util, and evolution-exchange. Is libedataserver a suitable library for utility functions used in e-d-s, evolution and evolution-exchange? Or should yet another library be introduced? Pushing functions into GLib is probably not feasible for Evo 2.6 as the GTK+ release cycle doesn't match Evo's.

Shreyas: We should really formalize libedataserver as the library which most of evolution can link to. This would mean moving all the duplicate stuff out of libeutil. Pushing into GLib should be pursued when possible as this would take away the problem of maintaining one more application library (remember gal ?)

  • Drop functions if there are full equivalences in GLib 2.8.
  • Go through the uses of strcasecmp() and strncasecmp() and check case by case what kind of strings they actually work on. Some random charset directly from an incoming (or outgoing) mail message? The current C library locale's charset? UTF-8? There seems to be much confusion in this area. Only for locale charset does strcasecmp() make sense, perhaps. For UTF-8 one first needs to g_utf8_casefold() the strings and the compare them using g_utf8_collate(). If the same UTF-8 strings are repeatedly collated, and performance is critical, one should precompute collation keys with g_utf8_collate_key(), store them, and compare them with plain strcmp(). For other cases what one really means would presumably be g_ascii_strcasecmp(). And check whether we actually want case-insensitive comparison in the first place in each case.
  • Use g_filename_to_uri() and g_filename_from_uri() instead of manually manipulating file: URIs. This is essential on Win32 as a file: URI looks like file:///c:/dir/subdir/file.ext, i.e. just stripping off file:// does not produce a legal filename. (The exact syntax and semantics of file: URIs on Windows isn't really specified anywhere I can find, but experimentation supports that the canonical syntax indeed uses three slashes and then the drive letter.) Ditto for the other direction, just prefixing an absolute pathname with file:// does not produce a correct file: URI.
  • There are several almost identical implementations of UTF-8 casefolding comparisons here and there in e-d-s and evo. Refactor these out to a single function in some sensible place (libedataserver?).
  • Move functionality between the various shared libraries and dynamically loaded modules to clean up the cross-dependencies, which are rather spaghetti-like currently.
  • The acinclude.m4 files in evolution, evolution-data-server and evolution-exchange are identical. It would be much better to rename the acinclude.m4 in e-d-s to evo.m4 (for instance), have e-d-s's Makefile.am install it in $(datadir)/aclocal. The acinclude.m4 copies in evolution and evolution-exchange can then be removed. When aclocal is run there it automatically fetches the m4 macro definitions from $(datadir)/aclocal.
  • If there are other common configure.in snippets copy-pasted between evolution, e-d-s and evolution-exchange, those should be made into m4 macros in a common evo.m4, too.

Suggestions by User:Andre:

  • work on the huge backlog of unreviewed Evo, EDS, gal and gtkhtml patches in bugzilla (and perhaps also on the e-p mailing list). one of the 2.4 goals was to be more community-driven. but people get annoyed/pissed if they submit patches, even update them from time to time, and do not get any feedback for months (examples: 1,2), to finally turn their back on evolution. be aware of that, review patches!
  • let evolution fail much more quiet instead of popping up two or even more windows with error messages of my IMAP server when my wlan is instable. to me this is one of the most important issues - it's is a huge annoyance and has been discussed and requested to death: bug 247373. thanks in advance, sigh... :-)

Suggestions by Shreyas

  • Split all the components which are currently being built into a single dynamically loadable module (link=no) into a dynamically loadable module and a shared library (link=yes). This makes the plugins portable and also removes the horrible *non portable* warnings spewed while building plugins.

Suggestions by Kaushal

  • Have an option to cancel a calender event. Delete is available. A use case scenario is when the user receives a meeting cancelled notification, he/she should be able to visit the calender event and cancel it. The cancelled appointments could show as strikethrough text in the list. Delete removes the history of the event, which the user might want to preserve for reference.
  • In Calender (click on the calender button), a right click on any appointment has options like 'Move to Calender', 'Copy to Calender'. These two options are not intuitive. Moving a calender event, while already in calender, to Calender makes it un-intuitive.

Suggestions by User:fullo

  • add pop3 plugin to delete a mail older than n days. This feature is present in a lot of different mail client, but missed in evolution. A bounty like this is published on the evolution bug tracker (bug 201824) but no one has yet tried to solve it.
  • mail archive export ability to different formats (mbox, maildir, pst, csv)

Suggestions by User:horga_83

  • Printing ***really*** needs it's own choice of font size, independant of the message viewer. Printing an email when viewing a message in say size 12 font or larger is just nuts. It's spread out over two or three pages when it could easily be on one.

Suggestion by User:NR:

  • Task list: it would be really useful to be able to split tasks into subtasks.
  • Calendar / task list: it should be possible to relate contacts to events or todos (especially if you plan to integrate features concerning organizer/attendees)
[edit]

Easier Approach to distribute Plugins

  • A new interface to push and install plugins.
  • Get Plugins/ Install Plugins functionality.
  • Online store for developers to upload new plugins frequently
  • Ablility to uninstall/install plugins from its current behavior of Disable/Enable
[edit]

Exchange Features

  • You can find the full list of features being done for Exchange here
  • And everything specific to Exchange here
[edit]

GPG


User:mayhem ask:

  • It would be nice if I we could have a "Always encrypt if recipient's gpg public key is present in my repository" and a "Search for recipient's key on public server" (may be with a text box to specify on wich keyservers).
User:guenther This is a security desaster. Some sort of "Always encrypt" is fine and would be a good feature to implement. But the "if gpg key is present" will lead to mails being not encrypted, cause the key is missing. If the key is missing but encryption is requested, the mail must not be sent.
User:bugreports I disagree. A mail that will be successfully crypted could be displayed yellowish as e.g. firefox does it - so no mixup can happen.
  • It would be really great if both attachment and inline encryption styles were correctly interpreted inside evolution, so I am no more required to cut and paste the text into a xterm...
User:andre: inline support has been in evolution 2.3.7 so this is obsolete.


User:jmcnaught suggests:

  • having a button or menu option to attach my public key, instead of having to attach a pre-created key file.
User:guenther I don't see, what this is good for. Use a keyserver.


User:andre votes for simple improvements of usability:

User:reinhard I second this


User:reinhard suggests:

  • By default, encrypt replies to encrypted mails.
  • Add support for signing/decrypting with OpenPGP cryptocards (GPG supports this, but evolution hangs if this feature of GPG is used).
[edit]

GtkHTML

User:Kaushal

  • HIG'fication of Insert/Format/Find/Replace dialogs.
  • Dialog stacking improvement. Currently the utility dialogs hide behind the other open windows when a switch is made.
  • Improvements to the printing layout.
    • UI to change the print fonts and especially the font sizees independently from the display font.
    • Nicen up that ugly layout.
User:guenther Printed mails are ridiculously ugly. Printing layouts need to be improved and nicened up. Different settings for fonts are necessary too. Not sure if these issues are filed already in bugzilla, but I'm pretty sure they are. See the recent discussions on the evolution-list.
  • Composer should display line, column number for current cursor position.
[edit]

W32/x64 porting

  • It will rock Outlook!
Retrieved from "https://go-evolution.org/index.php/Evo2.6"