Hi, On Wed, 2007-11-14 at 23:56 -0700, Sankar P wrote: > Hi All, > > Some of the issues that were discussed (here and in #496839) and my > personal take on them will be: > > 1) Plugin list being un-manageable > > I am thinking of adding a smart-search-box which will query based on > plugin-names and pre-defined-tags associated with each plugin. This will > make it easy to find out the plugin that you are looking for. > > Do you have any suggestion for how you want the Evolution Plugin-manager > to look like ? Can you send any mockups that you have in mind ? To me, this just sounds like a work-around for the problem of simply having too many plugins, although it will probably work OK if the current system is kept. > 2) Some plugins should not be shown > > This may not be possible as people may not want a functionality > implemented by a plugin. Disabling this plugin helps them to save > screen-real-estate (menu-items etc) and reduces memory foot-print. > > If any of the core feature is implemented as a plugin, I accept that it > should not be shown in the plugin-manager and will happily remove it > from the plugin-manager list. (It should have been core-code than a > plugin in the first place though) > > HTTP Calendars and IMAP Featuers are not core features since it may not > be needed by everyone. Say a corporate Evolution-GroupWise user. > > 3) Splitting Evolution into individual applications > > I have seen this asked by people a few times. But I wonder what good a > mail-client or Calendar-client will be without an addressbook. We currently have the other extreme: several different applications each have their own take on the address book (and then each have their own different ways of integrating/syncing it with e-d-s). Why not just have one desktop-wide address book (I'm thinking Soylent here), and have the mail application use that instead? This would give us the opportunity to swap out the address book application in favour of other things if necessary, such as an application which would use some web service as an address book. > Evolution shell will not load a component (Tasks or Notes) unless you > click open the component (except for addressbook) explicitly. But some > people have a mis-conception that all components are always loaded (and > hence consumes memory etc.) I must admit I had that misconception, and I'm glad to hear that Evolution lazy-loads things like this, but I can't help thinking that it's a bit of a work-around for having a program which is just too big. > IMHO a better approach will be to make the user choose what components > he want to see in his Switcher. Say if someone wants to use only Mailer > and Address-book, do not bother showing the Calendar component in the > switcher. But that's effectively like turning the components into plugins, and then disabling some of them; it comes back to the problem that core functionality shouldn't be in plugins, and you might as well split off such plugins into separate applications. > Atleast for me, It will be far more useful than launching two or three > applications everyday morning (Mail/Calendar/Tasks) Isn't that what your startup programs list is for? :-P Regards, Philip > 4) Evolution Preferences Dialog is Horrendous > > Yes. This is a terrible thing to have especially when you are working in > low resolution. The reason why this was so mammoth was because even the > plugin configurations were added to the General preferences. > > >From 2.12 onwards, we have Configure support for plugins and hence > people can configure plugins within the plugin-manager window itself. > > attachment-reminder plugin's configure UI has been already moved from > General preferences to Plugin-Manager-Configure already. Work is on for > Automatic-Contacts and other plugins already. > > One another option will be to show the preferences of the current > component alone. Like if you launch preferences from Mailer component > then only Mailer preferences should be shown. >
Attachment:
signature.asc
Description: This is a digitally signed message part