Re: [Evolution-hackers] GnomeDruid migration

[Srinivasa Ragavan <sragavan novell com>]

On Thu, 2007-05-10 at 16:07 +0200, Gilles Dartiguelongue wrote:
> Le jeudi 10 mai 2007 �5:40 +0530, Srinivasa Ragavan a �it :
> > > 
> > > So, what should be done here, indefinitely keep the current
> > > implementation or get rid of one more part of libgnomeui and simplifying
> > > evo's implementation ?
> > 
> > I would prefer to move to GtkAssistant but then it should still support
> > the existing EConfig structure. Hula/Groupwise/Exchange and other
> > providers will directly hook into EConfig via EPlugins.
> > 
> > I haven't yet seen much into GtkAssistant but it should be possible to
> > get it working.
> 
> great,
> 
> I should add that I wanted to make the necessary changes to the plugins.
> too if necessary (I believe that mixing GnomeDruid and GtkAssistant is
> not cool at all unless you want to express your mad g_object skills :) ).

I dont want to mix really. We can stick to Assistant. Just before that,
I'm planning for some one to take up UAM. In which case, I want to push
Account setup/Assistant out of Mailer to Shell or it can very well be
part of Control-Center as a capplet from Evolution. (Just a floating
thought!) In which case, Im afraid that the work could be duplicated or
obsolete. Too early to say but stuff to think off.

> 
> As I said, the biggest difference is that GnomeDruid bases it's
> operations on the access of next and previous page through pointers
> which is not the case with GtkAssistant. We could simulate that
> obviously but I think the result wouldn't be easy to either debug or
> maintain.

I really don't want unmaintainable code, its pain. I prefer to refactor
the EConfig code to fit Assistant's architecture, if that make sense.
But as I have said earlier, I haven't yet looked into GtkAssistant. But
it shouldn't be hard to file apis against it to get better APIs just for
the sake of easier migration. We may then do it at the next release or
so.

-Srini

>