Re: [Evolution-hackers] Spliting evolution into several programs

[Diego González <diego pemas net>]

On Sun, 2007-04-01 at 13:45 +0530, Srinivasa Ragavan wrote:
> This is same as what I have demoed in last GUADEC (Vilanova 2006). I
> have attached that pre-alpha patch that I have used in my demo. But I
> felt that it shouldn't be the way to go. I can list the problems with
> this approach.
> 
> 1. Account setup lies with Mailer (Exchange/GW will have issues around
> this)
I see.

> 2. Plugins aren't associated to any components. The EPlugin framework
> has to load the plugins depending on the component loaded.

Yes, this is true, i forgot to say that i disabled eplugin because of
this same reason, but it should not be difficult to check the class of
the plugin and load it according to this.

> 3. Though the shell gets invoked multiple times, the window pops out but
> the process dies after that as it creates a new view out of it.


> 
> Ideally for the split we should do the following things before that
> 
> 1. Move the account setup out of Mailer
Ok, the interace for the ConfigComponentes could be migrated to eplugin
for example and the setup of accounts could be present in *all* the
applications, alternatively the account configuration windows could be
pushed to EDS (libedataserverui), as it should be common to every
component.

> 2. Move away from libbonoboui to Gtk based menus
Yeah, but this requires *A LOT* more work, i think that if we could get
a split based on bonobo, then the components could be moved one by one
from bonobo, depending possible on how much the people used them or
according to the expect number of people that could contribute. 

Moving definetly away from bonobo if the split is done this way is
something that a user should not see, only developers.

> 3. Have the shell interface for a all-component view (like what is there
> today)

Well to do this *without* bonobo and making it easier we could launch
each application if the switcher buttons are used, i don't know it it is
optimal but i think it would be the easier thing other wise we could
probably need to recreate bonobo. And if so, it is better to stay as we
are today, at least bonobo has been debugged extensively.

> 4. Have evolution-mail, evolution-calendar, evolution-contact, etc as
> separate binaries. They should have a main function, that creates a
> GtkWindow and creates the menus, toolbars, preferences dialog and partly
> the required plugins. Some of this can be achieved via the shell
> library, need to explore more on this.

Like my patch?, i have a library that is called libshell that contains
everything in shell/ but the main functions and what was under
libeshell.
> 
> 
> > 
> > a) not all the plugins can be used
> > b) the system that lets you add an address from the mailer does not work
> > as it requires functionality that belongs to the Address book component.
> > c) It is a Bonobo split, meaning that all the components and mostly
> > useless bonoboUI code is still there
> > d) I don't really know what to do with the memos and notes components
> > that belong to the calendar.
> 
> They too can be separate apps. Althought the calendar provides a unified
> view.
> 
> > 
> > All in all this can be the begining of a crusade to remove BonoboUI (the
> > rest of the bonobo that is used in evolution is for communication with
> > EDS, but i believe there is plan and even a patch to port it to DBUS)
> > from Evolution and split it into 3 components, it only took me 3 hours
> > without knowing anything at all about evolution.
> > 
> DBUS port is to replace BONOBO in eds for IPC etc. It has no other stuff
> here in Evolution.

Yeah, that is what I tried to say the DBUS port would only remove
communication from EDS to Evolution, then you would have to remove the
UI parts which makes the integration of the 3 compnents into the shell.


---
Maybe the plan of action could be to get a nive split based on your
patch or mine solving the issues with the accounts, the plugins and the
general shell.

The user would actually see the split and that could be achived for
gnome 2.20.

And then pregesively remove bonoboUI from each of the applications. but
there is no need to hurry in this case, it can be done as time permits.
I don't know. If there would be several people participating in this
effort i could contribute some time, but moving away from Bonobo is
going to require a pretty big investment on time, because as i see it
when there is a decision to move one component/program away it will stop
working until every bonoboUI trace has been removed from it.


Best regards,
Diego