Re: [Evolution-hackers] PIM application suite

On Pre , 2004-04-16 at 14:27 -0400, Jeffrey Stedfast wrote:
> On Thu, 2004-04-15 at 15:41 -0700, Tristan O'Tierney wrote: 
> > is there any plan to split evolution up into separate
> > entities that manage calendars, contacts, and email
> > individually?  i use a mac every day, so the
> > difference between the ical/mail/addressbook combo is
> > quite apparent when compared to do-everything mail
> > clients like evolution and outlook.  i think, in
> > striving to do everything, they do everything poorly. 
> so... how do you envision splitting evolution up into multiple
> components making it better? I don't see it...
> will magic fairy dust come into play? :-)

Yes. The magic fairy dust making everything be even faster, and allowing
us to work
individually to simplify the UIs more as well.

> > making one application have too much functionality
> > also decreases it's usability (which thankfully gnome
> > cherishes unlike KDE), however in this case even KDE
> > got it right.  they too use separate applications.  so
> > i suppose i'm asking for a petition of some sort to
> > split the evolution application in to a suite of
> > well-integrated programs that work together and do
> > each individual task well
> wait. you mean, you want it to do exactly what it already does? :-)
> they basically *are* separate applications already, except they get
> embedded into a single window.
> they are just applications that happen to be shared libraries that get
> dynamically loaded by the shell application rather than separate ELF
> executables.

Right. But from a usability perspective, it deters from associative
actions. There's
also a lot of corba stuff going on at startup still, that we can
decrease by quite a
bit by splitting things up into actual separate binaries, rather than
shlibs. So,
that's probably where most of the speed gains will come from, even
though we are
pretty fast now already in 1.5 because we got rid of a lot of the shell

> >  rather than all tasks in a
> > cluttered interface.  because quite frankely, i never
> > go to my email program to add people to my address
> > book, nor do i go to my calendar program to check my
> > email.
> evolution doesn't force you to do that, so I don't quite follow.

Point above about associative actions. If everything is the same
application, and
people use that application most often for mail-related activity, then
it gets
associated that the address book and calendar are part of mail.

> >   the benefit of having an official gnome
> > addressbook app would be a great benefit anyways.  the
> > way mac os x utilizes the addressbook for aim names in
> > ichat is simply wonderful.
> evolution 1.5 already does that

Except nothing *really* uses it. There is a gaim plug-in that can
optionally depend
on the evolution stuff. I think there is a patch for gossip as well, and
there are
a few other things starting to use evolution-data-server for contacts
and calendar
information, like GnomeMeeting.

> >   it makes managing
> > names-->mediums 10 times simpler.  i hope some day
> > gaim works with such a standarized addressbook.  i
> > know evolution 2.0 is supposed to make a server for
> > all these activities, but that isn't a replacement for
> > what i suggest.
> why not?

It's not a replacement, because it's a subset. Evolution is the gnome
address book,
calendar, and mail app. There is no doubt about that really. It's
basically been that
way for a while now, and we will be in the desktop release
soon as well. The
only reason we weren't in 2.6, was because we didn't have the time to
get 2.0 done in
that time frame, because of all the changes and the bounties. And, as I
stated above,
gaim can work with evolution-data-server if you build the plug-in and
enable it. And
we are moving in the direction of totally separate apps. We just don't
have the time
to go full-haul for 2.0, or 2.2 really.

-- dobey

Attachment: signature.asc
Description: This is a digitally signed message part

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