*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 - [EMAIL PROTECTED] > > http://lists.ximian.com/mailman/listinfo/evolution-hackers > > _______________________________________________ > evolution-hackers maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-hackers > _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
