Re: libgnome deps
Fernando Herrera wrote: Sorry about this, I have been terribly busy these last weeks, expect new bug-buddy stuff coming during GUADEC. Salu2 On 7/10/07, Jani Monoses [EMAIL PROTECTED] wrote: Ross Burton wrote: On Wed, 2007-07-04 at 02:24 -0400, Matthias Clasen wrote: Personally, I'd make gnome-session do that for now, get this into G2.20, and then think about a location for GTK+ modules which are always loaded. Whats the problem with using the Gtk/Modules XSetting that was invented especially for this purpose ? Ah, I never knew about this. Please bug-buddy maintainers, apply one of the patches! :) Any news on this? :) I just saw that the support for this is now in the latest gnome-session and bug-buddy :) Does it mean that modules shipped as part of GNOME 2.20 that only use gnome_program_init() for hooking into bug-buddy can now replace it with gtk_init() ? One such app is gnome-screensaver, thanks Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgnome deps
Fernando Herrera wrote: Sorry about this, I have been terribly busy these last weeks, expect new bug-buddy stuff coming during GUADEC. Salu2 Is there a separate entry in bugzilla that deals with only the GTK_MODULES part of this? Is there any way one can help moving towards decoupling bug-buddy setup from gnome_program_init? thanks Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
bonobo deprecation status?
Hello, the bonobo related info on live.gnome.org is scarce;it is mentioned as scheduled for deprectaion in the future with the single explicit reference being gnome-panel in 2.22. Another place mentions apps are being actively migrated away from it. Can someone sum up or point to an overview of what are the most common changes needed and what besides D-Bus is meant to replace specific bonobo APIs? Is there any module that is being converted for 2.20? thanks Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
libgnome deps
Hello, As with gcalctool, I've filed a few patches to reduce some libgnome deps in n-m, g-s-s and g-p-m Since the respective bugzilla threads are not very alive I thought I'd bring up the issue here. I'd also like to know if there is a general shared sentiment in the GNOME project regarding Project Ridley: apparently nobody opposes its goals, but relatively few maintainers are proactive in keeping their modules as clean as possible given current GTK. Like with performance, cleanup is seldom explicitly in the roadmap, which is mostly feature-oriented. If it's up to each maintainer then it is harder to make progress than if if was generally agreed upon, and if something close to a consensus is not taken the tendency is to wait and see what others do, and again things progress too slowly. Maybe very clear bits of elimination of libgnome APIs can be GnomeGoals? here are the 3 bug reports delaing with gnome_show_url() and gnome_help_display() mostly. http://bugzilla.gnome.org/show_bug.cgi?id=436832 http://bugzilla.gnome.org/show_bug.cgi?id=436818 http://bugzilla.gnome.org/show_bug.cgi?id=399818 the benefits besides having somewhat lighter apps is that some of the GNOME modules would more likely be adopted by other projects - in particular Xfce - instead of them doing something from scratch or maintaining existing similar projects using the valid excuse that there are too many dependencies in the GNOME ones. thanks Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgnome deps
Richard Hughes wrote: On Tue, 2007-07-03 at 12:18 +0200, Jani Monoses wrote: the benefits besides having somewhat lighter apps is that some of the GNOME modules would more likely be adopted by other projects - in particular Xfce - instead of them doing something from scratch or maintaining existing similar projects using the valid excuse that there are too many dependencies in the GNOME ones. The only things that's stopping me applying the patches for g-p-m are: * We duplicate a lot of logic for just opening a help file, I'm not happy about all the copy and paste code in every module just to open a help file. Maybe we can get this split off into another (tiny) helper library? I agree copy-pasting sucks. But in this case even if the helper library is tiny it will likely cause more copy pasting and complexity (add autoconf props, new dependencies for packagers, a longish process until it's agreed upon what the lib should contain and API stability concerns..). IMHO we should have less libs and byte the bullet and deal with one copy pasted function once in a while until it gets into existing platform libraries. OTOH if it's an egglike library, you have copy paste as well... * Getting rid of gnome_program_init removes bug-buddy integration. This is a killer from my point of view. Can we _easily_ use bugbuddy without gnome_program_init? I agree with this as well. While there are modules that do not gain much from bug buddy, some often get valuable reports from it. Originally I though bug-buddy as external lib effort is in the 2.20 timeline but it does not appear to be so, probably because that project is more ambitious than just moving out bug buddy from libgnome. Anyway another option until that is fixed is having --enable-gnome as a config option. Quite a few GNOME modules have that so they can optionally run in non-GNOME desktops be it Windows, Xfce or low memory devices. This is probably up to the maintainer to consider, but in most cases it is one #ifdef choosing between gnome_program_init and gtk_init, so definitely not a maintenance problem after the initial routine patch is applied. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Remove libgnomeui where possible?
Bastien Nocera wrote: On Wed, 2007-05-09 at 10:06 +0200, Jani Monoses wrote: Richard Hughes wrote: snip with these applied the above apps only have gnome_program_init() from libgnome, and according to Fernando Herrera bug-buddy will probably be available via GTK_MODULES in 2.20 so the only reason for not using gtk_init() will disappear. Is there a bug opened for the bug-buddy gtk+ module integration? Possibly this one, it was mentioned when this thread started months ago http://bugzilla.gnome.org/show_bug.cgi?id=388441 Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Remove libgnomeui where possible?
Richard Hughes wrote: A bug [1] has been opened recently for gnome-power-manager which removes the use of libgnomeui which reportedly makes the applications startup quicker (as about 25 less libraries are loaded) and use a lot less memory. I've not tested this myself, so this may be wildly inaccurate. Now, while the rest of the patch is hardly invasive, replacing gnome_program_init with gtk_init removes bug buddy support and maybe other stuff I'm not aware of. I think gnome-power-manager needs bug buddy integration, so this might be the killer of this patch. So the real question is, do we really need to load the whole of the giant libgnomeui just to integrate with bug buddy and open a yelp file? Is using libgnomeui essentially cost-free if it's being used by other open programs? Should libgnomeui be chopped into smaller pieces? Am I asking too many questions? :-) Thanks for any feedback, Richard [1] http://bugzilla.gnome.org/show_bug.cgi?id=399818 I've updated the above patch to only contain the non-invasive part, and also filed similar ones against screensaver and nm-applet: http://bugzilla.gnome.org/show_bug.cgi?id=436818 http://bugzilla.gnome.org/show_bug.cgi?id=436832 with these applied the above apps only have gnome_program_init() from libgnome, and according to Fernando Herrera bug-buddy will probably be available via GTK_MODULES in 2.20 so the only reason for not using gtk_init() will disappear. comments are welcome Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
minimal required version of GTK for GNOME 2.18
Hi, is there a minimum required GTK+2.0 version that modules in svn trunk should depend on? I could only find the external dependency list in the wiki but that does not mention gtk. The modules in svn are not exactly the same as the ones that are part of 2.18 but still. Are there still cases when GTK 2.4 is targetted? Some that require 2.4 only are not part of the desktop (eggcups, gnome-cups-manager), network-manager-applet has no versioned dependency but uses a version check against 2.4 in the code, gnome-games does the same even if it requires on 2.8. Grepping the modules I have checked out locally shows very diverse requirements. ./gdm2/configure.ac:GTK_REQUIRED=2.6.0 ./file-roller/configure.in:GTK_REQUIRED=2.10.0 ./gnome-session/configure.in:GTK_REQUIRED=2.3.1 ./gnome-system-tools/configure.in:GTK_REQUIRED=2.9.0 ./eggcups/configure.ac:GTK_REQUIRED=2.4.0 ./gnome-cups-manager/configure.in:GTK_REQUIRED=2.3.1 ./gnome-power-manager/configure.in:GTK_REQUIRED=2.10.0 ./evince/configure.ac:GTK_REQUIRED=2.8.15 ./tracker/configure.ac:GTK_REQUIRED=2.8.0 ./gnome-games/configure.in:GTK_REQUIRED=2.8.0 ./zenity/configure.in:GTK_REQUIRED=2.9.2 ./gnome-utils/configure.in:GTK_REQUIRED=2.8.0 ./brasero/configure.in:GTK_REQUIRED=2.10.0 ./gnome-system-monitor/configure.in:GTK_REQUIRED=2.8.0 Looking for ifdefs in the sources yields similar results ./eggcups/ec-tray-icon.c:#if GTK_CHECK_VERSION(2,6,0) ./gnome-games/dependencies/ggz-gtk/xtext.c:#if GTK_CHECK_VERSION(2,4,0) ./gnome-screensaver/src/gnome-screensaver-preferences.c:#if GTK_CHECK_VERSION(2,10,0) ./gnome-utils/baobab/src/baobab-graphwin.c:#if GTK_CHECK_VERSION(2,8,0) ./gnome-utils/gsearchtool/gsearchtool-callbacks.c:#if !GTK_CHECK_VERSION(2,7,3) ./gnome-utils/gsearchtool/gsearchtool-callbacks.c:#if GTK_CHECK_VERSION(2,7,3) ./libgnomeui/file-chooser/gtkfilesystemgnomevfs.c:#if GTK_CHECK_VERSION(2,7,0) ./libgnomeui/libgnomeui/gnome-popup-menu.c:#if GTK_CHECK_VERSION(1,2,1) ./network-manager-applet/src/applet.c:#if GTK_CHECK_VERSION(2, 11, 0) ./network-manager-applet/src/applet.c:#if !GTK_CHECK_VERSION(2,6,0) ./network-manager-applet/src/applet.c:#if GTK_CHECK_VERSION (2, 6, 0) ./network-manager-applet/src/menu-items.c:#if GTK_CHECK_VERSION(2,6,0) ./network-manager-applet/src/other-network-dialog.c:#if GTK_CHECK_VERSION(2,6,0) ./tracker/src/tracker-search-tool/tracker-search-tool-callbacks.c:#if !GTK_CHECK_VERSION(2,7,3) ./tracker/src/tracker-search-tool/tracker-search-tool-callbacks.c:#if GTK_CHECK_VERSION(2,7,3) ./vino/server/vino-status-icon.c:#if GTK_CHECK_VERSION (2, 11, 0) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Remove libgnomeui where possible?
Sure, but my point really is that gnome-power-manager is a pretty typical application and so memory hacks like this should probably be generic. Maybe even a creating a libgnomebugbuddy might solve the issue. It was mentioned last year in an a11y thread on this list that as an alternative, bug buddy could be a GTK module loaded depending on XSettings. Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Remove libgnomeui where possible?
It's not that tricky to copy and paste the libgnomeui code that handles sigsegv and calls bug-buddy, the code is pretty small. I'd do that. Maybe GTK+ should have a hook for a process to call on sigsegv... That's obviously the right thing to do. Same goes for Help support. Copy pasting in the app itself is uglier imho than having another egg module. The latter would at least be co-maintained by those who need it and easier to sync among apps using it. These are the functions I remember needing to c/p for being (partially) independent of libgnomeui in various programs: * gnome_help_display() - replaced by g_spawn_xxx * gnome_url_show() - ditto * gnome_password_dialog (ex: in gnome-mount), repaced by a 4 file copy paste from libgnomeui * various gnome_vsf URI functions which have glib equivalents (ex: in gnome-system-tools) And there is the new eggsmclient module which I have tried but not yet submitted patches to any module. (Which regardless of whether keeping XSMP or dropping it is the best idea for the future it helps lessen this memory usage problem) Also there are other uses of libgnomeui APIs with gtk equivalents but have not yet been switched. Almost any module maintainer will surely find at least some such bits in his/here code. Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Remove libgnomeui where possible?
Sounds good in theory, *but* modules in libegg need an exit strategy (ie. a lib that they are destined for). Code isn't meant to live in libegg forever. Of course not. Most are probably meant for GTK and in the Ridley wiki. But until a GTK+ version that contains all libgnomeui equivalents is released and GNOME apps converted to it, it would be nice to have some measurable memory reductions between GNOME releases as opposed to having to present performance improvements which affect only corner-cases (i.e gnome-terminal scrolling millions of lines of text faster than previously). Also startup time is not to neglect, but I guess with much of our time spent in web-browsers we all got used to high latency and it is not surprising anymore that an app can easily take over a second to launch. So the changes brought up here are less than ideal as they use copy pasted code, but they'd at least emphasize in each app which bits are still legacy or GNOME only instead of being spread all across it. Since these can be done step by step they may make good candidates for GnomeGoals. Last but not least it would be a diplomatic statement (for lack of better words) towards other GTK environments and developers (embedded, Xfce, XO) and would encourage cooperation in some areas as opposed to gratuitous duplication. Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
James Henstridge wrote: On 26/07/06, Fernando Herrera [EMAIL PROTECTED] wrote: On 7/26/06, James Henstridge [EMAIL PROTECTED] wrote: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. So if we are moving to this solution we could also add a gnome_segvhandler module to this XSETTING in order to get gtk_init load this module installing the segv handler, right? That would probably also be possible. With all the recent work on bug-buddy, would it make sense to make it such a runtime loadable module as suggested in this thread months ago? I think the a11y toggle is already an xsetting, so this could be one of the last steps towards converting some apps to use gtk_init instead of gnome_program_init and getting rid of the spurious dependencies the latter imposes. thanks Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: patch to vino 2.12.0 to remove gconf dependency
Hello any patch that tries to reduce the footprint of Gnome apps while retaining their functionality is a good contribution as long as it is not a hack ;) Most of the times it is harder to make the changes clean and maintainable than simply finding the places that need rewriting or placing the ifdefs. For distributors to use this, it should not incur extra maintenance burden. For the specific vino patch you sent * work on the most recent version (2.13.X I think) even if in this case they may be the same if vino is not actively maintained * split in smaller and self-contained patches. This is too often repeated but it really matters especially if the maintainer you are targeting is busy. * better than using ifdefs try to see if there are non-gnome libraries which can replace the functionality you compiled out. This way there is no need for conditional compilation and two binaries built from the same source (an easy one here is to replace the deprecated gnome_icon with gtk_icon, and that should get rid of the libgnomeui dep. A much harder one may be to see if bonobo usage can be replaced by dbus or entirely eliminated) * if not all gnome APIs are replaceable, only then resort to ifdefs in which case they have to be named appropriately * gconf is not the biggest issue here, it's a small dependency compared to bonobo/libgnomeui, not to mention that using an entirely new and incompatible config format for vino may not be a good idea at this stage As this may be of interest to those integrating vino into a non-gnome (esp. non-gnome, but gtk based) desktops or distros, I'm copying this to the xfce and (x)ubuntu lists. I removed the xfce and ubuntu lists from Cc as this is not on topic there even if there may be interest; in that case the interested people should be subscribed here ;). Besides, I think it actually decreases the chances of you being answered, as everyone will think someone on the other lists will, especially when the subject is not a new shiny feature but the boring and inconvenient issue of keeping the memory usage low. Disclaimer: I am not related to vino or Gnome in any way so you may want to wait for someone more authoritative to answer, but I am interested in such changes that make Gnome apps lighter. Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
James Henstridge wrote: I think you'll agree that we want a11y enabled for all GTK applications, and the best way to do this is to make the initialisation happen in gtk_init(). The gtk-modules XSETTING makes this possible. The proposed method of getting things loaded is: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. 2. in gtk_init(), GTK sees that the gtk-modules XSETTING is enabled, and loads the listed modules. 3. in the libgnomeui specific gnome_program_init() code, check to see if the accessibility gconf key is set and load libgail-gnome. This setup should make sure that all GTK applications load the GTK accessibility modules, and all libgnomeui applications load the libgnomeui-specific accessibility modules. If this is agreed upon is it possible to make it for 2.16? Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GnomeClient replacement?
Hello, the GnomeClient API is for some apps the single Gnome dependency that has no GTK equivalent and that keeps said apps tied to the 25 or so platform libraries. Other libgnome(ui) uses are gnome_program_init() and gnome_help_display() which can be replaced by gtk_init variants and directly spawning gnome-open or yelp. Could there be a per application analysis of whether GnomeClient is really needed and whether it can be discarded or replaced by using the simple X API directly? I see it's on the Ridley TODO list but with no alternative proposed. thank you Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
