Sorry to join late in the discussion, just back from my vacation. On Fri, 2007-11-16 at 11:38 +0100, Vincent Untz wrote: > On mer, 2007-11-14 at 23:56 -0700, Sankar P wrote: > > 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. > > Heh. Bad examples :-)
Right. Local Addressbook/Calendar are better examples for core features as plugins. HTTP Calendars is debatable. IMAP features is named/described wrongly. It just provides a feature to select the headers to download and nothing core other than that. > > I've opened the plugin list five minutes ago, to take a look. I wondered > why there were so many "core" plugins. So, looking at both examples > you're giving: > > + HTTP Calendars is described as "Provides core functionality for > webcal and http calendars.". I'm a user who doesn't know anything > about technical stuff: the plugin provides core functionality, so I > enable it. I'm a user with a technical background: "oh, there are a > lots of calendars on the web now, I want this to work, just in case" > > + IMAP Features is described as "A plugin for the features in the IMAP > accounts.". Right. I have absolutely no clue what it's supposed to > do. I guess evo still supports IMAP without this plugin, so why not > support IMAP features anyway? > > Maybe 95% of the plugins of evo should not be displayed as plugins. They > should either be preferences in the standard preferences dialog, or they > should be enabled anyway. 95% is a bit much ;-) > > This is not only true for evo, rhythmbox has the same issue (although > there are less plugins there) > > (and of course, +1 for splitting evo) Vincent, at GUADEC 06 I demoed split. Even there was a external patch that was floating in hackers list some time back. Unfortunately all those break the assumptions of Evolution. There are lot more dependent issues which needs to be addressed before split. I guess it would take a separate release for that. The current team is focussing on stability/performance/bugs of Evolution and MAPI based Exchange connector. If we are out of MAPI atleast, we would definitely have more time to do things required for split. Split itself would take pretty less effort :-). Believe me that most of the team too understands it and we have already done some thoughts for its dependent issues ( http://www.go-evolution.org/UAM ) and it is part of our planning as well ( http://www.go-evolution.org/Evo2.22 ). I hope that we would have some dedicated resources for it pretty soon. -Srini. > > Vincent > > -- > Les gens heureux ne sont pas pressés. > > _______________________________________________ > desktop-devel-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
