Re: [Evolution-hackers] PIM application suite
- From: Nick NoSpam <nicknospam optonline net>
- To: evolution-hackers lists ximian com
- Subject: Re: [Evolution-hackers] PIM application suite
- Date: Sun, 18 Apr 2004 13:53:11 -0500
I agree that it would be nice if the non-mail functions of Evolution
were split out--but into standalone libraries, not executables.
If this is already the case, press delete now (and sorry for the wasted
bandwidth).
If not, here's my rational.
If each "component" were a separate library, they can be used by any
package. Likewise, desktops may wrap the library into an executable for
direct manipulation.
The library, of course, would basically be the gatekeeper to some
central repository for the corresponding component. For instance, the
contacts library would provide several interfaces to the contacts
backend (perhaps a database). The interface would publish accessors and
mutators (goal is to be very flexible).
Some examples:
- GNOME may provide a standalone "Calendar" executable
(Applications->Accessories->Calendar)
- Gaim may use the Contacts library
- Evolution may use the Calendar, Contacts, etc. libraries to
provide the functionality currently available.
etc.
So a change through one app is available in other apps.
I think the benefits of common, centralized, and independent components
are obvious and don't need explaining. In the end, a superset to each
component's backend can easily be recognized. It's this backend which
should be independent and shared--otherwise it's plain wasted effort.
The library may go so far as to provide a default UI. If requested, it
will be displayed (as outlined by the caller). This would permit
default Contact interaction to be the same between Evolution and Gaim,
for example. Specialized apps (or portions thereof) can pull the data
into a customized UI if necessary. For example, displaying only a
subset of Contacts.
Regards,
Nick G.
On Sun, 2004-04-18 at 10:42, Jeffrey Stedfast wrote:
> On Sun, 2004-04-18 at 05:03, Tristan O'Tierney wrote:
> > > the mailer will always depend on the addressbook and
> > > calendar, so
> > > whether you load them into the window or not is
> > > irrelevant.
> > >
> > > in fact, I don't see why you wouldn't just load them
> > > into the main shell
> > > window anyway, they're loaded!
> > >
> > > no sense making the user run 3 apps having each
> > > component loaded into
> > > each of them. it just wastes more resources.
> > >
> >
> > the GUI wastes far more resources than a command line,
> > yet the GUI is far more usable. resources are
> > irrelevant here, especially when 128 megs of ram or
> > more these days for a simple PIM suite. they should
> > be split up because they are different functions. not
> > because they aren't related. you simply aren't
> > understanding this. mail != contacts != calendar. yes
> > they are all INTERDEPENDENT. they are even related.
> > but they are not the same function, it's just that
> > simple. if you try and cram too much functionality
> > into one interface it's incohesive to the average
> > user.
>
> doesn't seem to bother the average user, if it did... there wouldn't be
> Outlook or GroupWise or Lotus Notes or... a zillion other groupware
> suites.
>
> in fact, you seem to be the only one (or, at best, one of a handful)
> bothered by this.
>
> > it's a linear function. the more options a user
> > has to choose, the more chance of failure to find the
> > option they want and the increased time to find said
> > option.
>
> how hard is it, really, to say "I want to make an appointment. I need to
> switch to calendar because obviously mail doesn't do that"
>
> you're saying the average user can't handle that, yet you want to split
> the applications which forces these users to have to know which
> application does what? it's the same bloody decision.
>
>
> > it makes interfaces scary and bloated.
>
> ah, bloated. the most overused and least understood word used when
> describing software.
>
> > i'm
> > not sure why you can't understand this.
>
> I'm not sure why *you* can't understand this.
>
> > the key to a
> > good application is focus.
>
> there is focus. where is there not focus? how is there not focus?
>
> > there's something to be
> > said about an app that does ONE thing well, and
> > strives only to do that one thing.
>
> ah, the good ol' "do one thing, and do it well" argument. the most
> widely used and yet least understood statement used by non software
> developers when trying to argue something.
>
> for a loose definition of "ONE", everything does ONE thing well and
> strives to only do one thing.
>
> if we split out the mailer, for example, would it really only be doing
> "ONE" thing? depends on how you define "ONE", obviously. It replies to
> mail, it composes mail, it forwards mail, it filters mail, it fetches
> mail, it sends mail, it displays mail, as well as numerous other things.
> That's not one thing... so I guess by your definition each of these
> functions should be a separate application too? :-)
>
> > this doesn't mean
> > this independent app can't fully integrate with other
> > related applications (like a calendar or contacts
> > program integrating with a mail app).
>
> if you completely split them, then yes, it would mean that.
>
> >
> > > evolution --component=contacts
> > then this should be the default
>
> no, I disagree.
>
> > , and there should be
> > several evolution-pim scripts installed by default as
> > evolution-contacts, evolution-calendar, and
> > evolution-mail.
>
> no, if a distributor wanted this, then they could make separate menu
> entries - one to launch each of the components. that would be the proper
> way to do it, not writing shell scripts. average users don't use the
> command-line.
>
> Jeff
>
>
> _______________________________________________
> evolution-hackers maillist - evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]