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

[Srinivasa Ragavan <sragavan novell com>]

On Sun, 2007-04-01 at 13:22 +0200, Diego Gonz�z wrote:
> 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.
This particular work has been referred as UAM (Unified Account
Management). I would put a strong dependency on this work before we
think of split. Or else except mailer, no other is useful. 

> 
> > 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.
I agree. This is a soft dependency. We can still live with out this in
split view. Just that the individual binaries got to be BonoboWindow and
have bonoboui instead of the gtk ones.

> 
> > 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.
Just dont change the existing things. Add the split binaries part of the
component, this requirement would be taken care automatically. 
> 
> > 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.
Similiar, I would say. Main lies in the respective components. You may
not launch the components via the bonobo interface, but pack them
directly. But leave the mail-component.c for the multiple-component view
as what is present today. Preferences will be launched directly instead
of the shell interface. Just the basic stuffs like plugins, etc (could
be more) will be part of the libeshell. No bonobo query stuff should be
here. 

> > 
> > 
> > > 
> > > 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.

Sounds good, if  we take this approach of solving leaving bonoboui apart
and going ahead with rest. But as I have said the UAM is a hard
dependency. May be that has to be closed first, before anything else.


If you are to take this up, Im all for it. I can help you where ever
required and lets target this for Evolution 2.12/GNOME 2.20. Feel free
to breakdown the requirement in the planning page at
http://www.go-evolution.org/Evo2.12

-Srini

> 
> 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
> 
>