GNOME Bugzilla – Bug 361134
Migrate from libgnomeui's about dialog to GtkAboutDialog
Last modified: 2007-02-17 12:05:07 UTC
Step 1 to GTK-only ekiga: get rid of the gnome-about dialog, replace it by its GTK counterpart, GtkAboutDialog, available since GTK 2.6. I'll hopefully cook a patch for this.
Seems the previous management was buggy... One could open as many about boxes he wanted. GtkAboutDialog dialog in instead cached and anly a single one can be displayed at once.
We are looking for help to migrate to GTK+ 2.10 and port such things. Is that something you are interested in doing? The Druid is the most difficult one.
Created attachment 74447 [details] [review] Use GtkAboutDialog You will have to delete the whole ekiga/lib/about directory, which became useless. I don't know how to put that kind of information in a patch. I've tried will cvsdo, but couldn't get it.
Sure Damien, I want to help you to avoid more bashing on linuxfr.org. Don't even go there, you always end up losing you mind ;-). Jokes apart, yes, I indeed opend these bug to try to help you in this migration, as I told you at GUADEC (remember, the guy on your right during the spain/france match :-p ). I finally found some spare time, and I preciouly kept the notes I wrote with Fred Crozat during GUADEC about some druid issues. Hopefully, I'll be able to get rid of the druid, what I'm most afraid of are regressions... I'm gonna see if it's better to start the GtkAssistant or the GtkStatusIcon migration.
First the about dialog, then the status icon, and finally the druid : since we're going to rework ekiga quite extensively, better not work on the piece of code which is the more likely to change :-) Thanks!
Ok, I'll jump next on the tray icon. For now I may rework this patch to implement some other details I noticed in http://live.gnome.org/GnomeGoals/AboutDialog , such as adding the licence, getting rid of the pixbuf loading stuff...
Well, seems I forgot too to change the GTK+ requirements: GtkAboutDialog exists since GTK 2.6, and we are currently depending on GTK 2.4. I think it should be ok, since that's no big jump. But both GtkStatusIcon and GtkAssistant depend on GTK 2.10, which is much more recent. For these, will it be acceptable to bump the GTK dependency to 2.10 ?
I'm not sure, but I think yes. Those patches will be integrated into CVS around November, and 3.00 shouldn't be released before March 2007. By that time, GTK+ 2.10 will be available everywhere. I think it is a great step forward and well-deserved. Notice also that while you are at it, you could also try to compile Ekiga with the DISABLE_DEPRECATED GTK+/GLIB flags and remove deprecated widgets.
Yes, yes, we'll depend on gtk+ 2.10 and get rid of a few things in lib/ ! I like it when code disappears :-) Do we use that many deprecated widgets ?
Shouldn't be that much, I cleaned a lot, but definitely not all.
Ok I: * added the license * removed the pixbuf * added GTK 2.10 dependency But I have 2 questions: 1. Should the name property be resolved by its defaul value ? People on http://live.gnome.org/GnomeGoals/AboutDialog seemed to disagree (search 'name'), so I let you choose... I would prefer to remove the harcoded string "Ekiga", the result with the default value would just be "ekiga", with the lowercae 'e', but would be app-changing-proof (and we know an app can change name :-) ). 2. bug 337358 implies that if we achieve not linking to libgnomeui anymore (because we use only fresh GTK widgets for example), the hook function for the website link will not work "as is". Can I leave it in the current state for now, or should I seek some code for the hook ?
Created attachment 74589 [details] [review] Second try With license, no pixbuf
Created attachment 74590 [details] [review] Third try Without the INSTALL file weird stuff ???
First of all, don't worry if it is not added now to CVS. We are simply stabilizing a few things before adding more new code. Secondly, thanks a lot for your contribution, it is highly appreciated and having new collaborators ROCKS. Now for your 2 questions : 1) I would prefer Ekiga than ekiga. Perhaps we could add a new #define through configure.in, just like we are doing for ekiga. 2) We already have our own hooks (see lib directory) for the non-GNOME GTK+ version. However, I think they ignore the gnome preferences which is not good. So I would say, let's keep libgnomeui for now and postpone the problem. Then we can extend our own hooks (later).
Thanks Damien for your encouragement :-) Ok, so the last patch was conform to what you expect. When commiting, don't forget to delete ekiga/lib/about. I'm now moving to GtkStatusIcon migration :-)
Created attachment 80815 [details] [review] Actual patch against HEAD Removed the enclosed configure.in version check for 2.10 entirely, as all active branches check for 2.6 (which is required by GtkAboutDialog). Tested with Trunk, compiles and runs.
Well, check out comment #8 : Dependency to GTK 2.10 was accepted by Damien. In fact this does not required GTK 2.10, but use of other functionnalities do (see bug #361678). I bumped to 2.10 to avoid conflicts during the merge. But as I still haven't put hands back on GtkStatusIcon migration, so I think it's better that way. If it's working for you, you can close this bug.
This change is not directly based on your patch. We needed to increase GTK+ requirement in any way. What I did (for this specific patchfile only, because its technical requirements are 2.6) was removing the configure.in changes to bump GTK+ check to 2.10, as I bumped it to 2.6 in all branches, *also in the GNOME releases branch*. When we pack all this together and put it in HEAD, the requirement will be 2.10, for the current releases (and maybe also the current W32 BETA ports of HEAD) the safest requirement for all operating systems is 2.6 IMHO (I don't dictate, please discuss!). On W32 systems, for older versions, 2.6 is needed, as 2.10 is for the NT-clones only. I don't know what the guys from Sun fiddle with at the moment. But I guess they have a very recent GTK+ version available (as porting UNIX to UNIX is always easier). Hope that clarifies what I intended. This specific patch works against current HEAD where the technical (not political ;-) ) requirements for it are met. I didn't doubt that HEAD should change to 2.10 as soon as safe from the windows-side (it will be safe for most installations, maybe my requirements for portability are too high - Damien?). J.
I can't find it applied in svn trunk... Is it supposed to be have been applied in a branch ?
Sorry, currently I work ~12h a day, I will sit down next weekend, hopefully, and apply it. It's in my TODO file since 2 weeks :( My apologies. @Damien: - target versions: HEAD, H_Release, gnome-2-14 - any comments? J.
HEAD only I suppose. H_Release would need a GTK+ upgrade.
Is there a minimum GTK+ dep. for the upcoming GNOME release? Maybe that fits... J.
Okay, figured out that this code won't work on --disable-gnome builds. I will rework it for that (W32 version!).
Okay, it was only an entry in src/common.h you have overseen, nothing important :) Committed to HEAD version (trunk). Leaving bug open until ported to 2.0.x. Thank you very much! J.
Committed to gnome-* branch, tested so far. If I broke anything for that branch, tell me. Thanks again, Luis!