Re: Evolution Plugins (Was Re: Rise of the Plugins)



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 won't comment much on the details about this in evo, but I do think
that the plugins idea has gone way off target and is causing suffering
an pain to users that get applications that doesn't do what they need
unless they know of some magic plugin to enable that feature. Also, I'm
pretty sure that they are not interested in micro-managing the plugins
list in order to save a few KB of ram.

In fact, I think the "less resource use" part of plugins is often just
wrong. Even small libraries do have non-negligible costs in the dynamic
linker, and having to write code that supports generic plugins isn't
gonna make that code more efficient. In fact, I think in many cases
plugins are just a way out of lousy/no UI design and thought. We just
make it plugins instead of preferences because Gnome has historically
frowned upon lots of preferences (for pretty much the same reasons I
think plugins suck).

> 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. 

This is kinda a backward question. The reason you want to split it out
is of course not because you want to use the mailer without the
addressbook, it is because you want to use the address book without the
mailer. 

Maybe you want to look up a phone number (and ideally dial it on your
phone via bluetooth, the osx address book can do this). Maybe you want
to launch ekiga or some other app via the address book. In none of these
cases do you even want to see anything about mail in the UI. And you
don't want to connect to some imap server and enter your password, or
get some mail config setup wizard (you might be using another app for
mail and still want to use the address book, since other apps use
e-d-s).




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]