Re: [Evolution-hackers] GnomeDruid migration
Am Donnerstag, den 10.05.2007, 11:05 +0200 schrieb Gilles Dartiguelongue: I looked at the sources to get a feel of how easy it would be to migrate from GnomeDruid to GtkAssistant. I've now filed http://bugzilla.gnome.org/show_bug.cgi?id=567260 about porting from GnomeDruid to GtkAssistent. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] GnomeDruid migration
Hi list, I looked at the sources to get a feel of how easy it would be to migrate from GnomeDruid to GtkAssistant. I started some work on the startup config plugin and on the new mail account glade part. At that point, trying to create a new account just crashes evolution, so I decide to look deeper. I found that currently wizards are intricated with notebooks in e-utils/e-config.c. Although it worked relatively well with GnomeDruid, I tried to adapt it to GtkAssistant without much success. It seems there is no easy way to get references to previous and next page other than by calculating the prev/next page id with GtkAssistant. On the other hand, integrating new pages into an assistant seems really easy. 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 ? -- Gilles Dartiguelongue [EMAIL PROTECTED] ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GnomeDruid migration
Gillies, On Thu, 2007-05-10 at 11:05 +0200, Gilles Dartiguelongue wrote: Hi list, I looked at the sources to get a feel of how easy it would be to migrate from GnomeDruid to GtkAssistant. I started some work on the startup config plugin and on the new mail account glade part. At that point, trying to create a new account just crashes evolution, so I decide to look deeper. I found that currently wizards are intricated with notebooks in e-utils/e-config.c. Although it worked relatively well with GnomeDruid, I tried to adapt it to GtkAssistant without much success. It seems there is no easy way to get references to previous and next page other than by calculating the prev/next page id with GtkAssistant. On the other hand, integrating new pages into an assistant seems really easy. 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. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GnomeDruid migration
Le jeudi 10 mai 2007 à 15:40 +0530, Srinivasa Ragavan a écrit : 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 :) ). 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. -- Gilles Dartiguelongue [EMAIL PROTECTED] ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GnomeDruid migration
On Thu, 2007-05-10 at 11:05 +0200, Gilles Dartiguelongue wrote: I found that currently wizards are intricated with notebooks in e-utils/e-config.c. Although it worked relatively well with GnomeDruid, I tried to adapt it to GtkAssistant without much success. It seems there is no easy way to get references to previous and next page other than by calculating the prev/next page id with GtkAssistant. On the other hand, integrating new pages into an assistant seems really easy. Can't you access the next page like so current_page = gtk_assistant_get_current_page (assistant); gtk_assistant_get_nth_page (assistant, current_page + 1); or am I misunderstanding the problem? If you want, I'd be interested in helping out with this. Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GnomeDruid migration
On Thu, 2007-05-10 at 16:07 +0200, Gilles Dartiguelongue wrote: Le jeudi 10 mai 2007 à 15:40 +0530, Srinivasa Ragavan a écrit : 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 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
