Re: [Evolution-hackers] PIM application suite

[Jeffrey Stedfast <fejj ximian com>]

*nod* this is the way it already works.

Jeff

On Sun, 2004-04-18 at 14:53, Nick NoSpam wrote:
> 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
> 
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
>