Re: [Evolution-hackers] Some suggestion for the future evolution

[Ettore Perazzoli <ettore ximian com>]

Hi,

> * i see the screenshots of the UI proposal for Evo 2, and that's what i
> think : 
>      - this is the works of the panel to start an application right ?,
> then it should be the role of the panel to "activate" (the user don't
> know how it works) the component to use. So i think there is no need of
> the 6 buttons block to switch betewen components.

The thing is, the integrated UI allows you to keep all your information
in one place.

This has been discussed to death already -- I think we are going to
stick with the unified UI at least for the time being.

> * i think too that it will be nice if evolution transparently provides 
> an access to data like addressbook, calendar,... to let others
> application don't care about where are the datas, an little app that
> show the addressbook, will just specify an addressbook name, and evo
> provide the API to access to it, but the app don't know if the
> addressbook is a file on the filesystem, of an ldap share... (idem for
> calendars,...)

Yes.  We want to provide public APIs to all the data that Evolution
manages.  Actually, we already have APIs but they were never finalized
enough to be used by other apps...  Part of the 2.0 plan is to fix these
APIs and make them more suitable.

> * then there could be a problem, if the source of the data is not
> available because of a connected/non-connected mode. This info
> (connected/not connected/ask for a connection/close connection/...)
> should be at the gnome level, eg: a applet or try app that display the
> connection status,...

Yeah, there needs to be a GNOME-wide plan to notify applications of
online/offline status change.  People are working on this, in particular
D/BUS which is a notification infrastructure.

> * why not get ride of db 3.1.17 ? and use other storage ? then just an
> importer (separatly packages, like the rest) that let import the old
> addressbook ?

We'd like to, but I don't know when this is going to happen.

The DB3-based approach has the advantage of not requiring us to read the
whole file at once (although we are not fully taking advantage of that
ATM) and also not have to rewrite it from scratch every time we change
something.

Of course, we could use a mbox-and-summery-like approach of some kind,
but that requires work and it wouldn't change much from a user's
perspective.

> * why not vfolfers views : contacts:/// (in nautilus) will show the
> contacts sources, and let launch the contact component to use it, and
> may be a mailbox file viewer ?

I am not a fan of the file manager doing everything, but in any case,
people will be able to implement that once we export the necessary APIs.

> * and the last (sorry for this one) why keep the "evolution" name to
> store evo's datas on the filesystem, wht no ".evoluton" ? or separated :
> .gnome2/mail .gnome2/calendar ...

Yes, for 2.0 we are going to move it into a hidden directory.

-- Ettore