GNOME Bugzilla – Bug 573670
Removal of libgnomeui
Last modified: 2009-05-19 02:15:27 UTC
http://live.gnome.org/LibgnomeMustDie gnome-thumbnail: For desktop applications there exists a copy of this in gnome-desktop called GnomeDesktopThumbnail (Note: libgnomedesktop is not API stable) $:andre\> grep -r gnomeui . ./gsearchtool/gsearchtool-support.c:#include <libgnomeui/gnome-thumbnail.h> ./configure.ac:dnl separate check for libgnome/libgnomeui ./configure.ac: libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED) ./gnome-utils.spec.in:%define libgnomeui_version 2.6.0 ./gnome-utils.spec.in:Requires: libgnomeui >= %{libgnomeui_version} ./gnome-utils.spec.in:BuildRequires: libgnomeui-devel >= %{libgnomeui_version} ./README: libgnomeui >= 2.13.2 ./gnome-screenshot/ChangeLog: Drop libgnomeui dependency (#557169). ./NEWS: * Fix bug #565388 - Drop libgnome/libgnomeui dependency ./NEWS: * Remove libgnome/libgnomeui dependency (#563970) [Cosimo Cecchi] ./gnome-dictionary/ChangeLog: Drop libgnome/libgnomeui dependency (part of #557262).
Fix is part of the gio patch in bug 543713.
The patch attached to bug 543713 will remove the gnome-thumbnail routines from gnome-search-tool, but it does not remove all uses of libgnomeui. I am waiting for a bug from 2004 to be resolved, bug 161483. Basically, gtk+ does not offer a replacement for the history-saving functionality of GNOME Entry.
Also, gnome-search-tool uses gnome-client from libgnomeui, bug 79285. Currently, Gtk+ does not offer its own session management support.
Patch to remove the use of gnome-thumbnail from libgnomeui applied on 3/16/09 to version 2.27.1.
According to http://www.gnome.org/~fpeters/299.html there's no libgnomeui includes anymore, but configure.ac still includes "libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED)".
*** Bug 582785 has been marked as a duplicate of this bug. ***
Created attachment 134751 [details] [review] [gsearchtool] drop lib[gnome,gnomedesktop] deps Use the GAppInfo facilities instead of GnomeDesktopItem to launch the file manager.
Created attachment 134752 [details] [review] [gsearchtool] drop GnomeEntry Copy/paste GEditHistoryEntry from gedit and use it to get rid of GnomeEntry.
Created attachment 134753 [details] [review] [gsearchtool] drop the last libgnome* bits Copy/paste EggSMClient to drop the last libgnome* bits from gsearchtool (and consequently, from gnome-utils).
These patches remove completely the dependency on libgnome* from gnome-utils. - I had to copy/paste GEditHistoryEntry and EggSMClient from gedit and libegg. - I put EggSMClient in a separate libegg toplevel directory, so that other gnome-utils applications can use it as well - GEditHistoryEntry instead is copied directly in the gsearchtool directory, as that's probably the only client Personally, I think it's not that harmful to ship these files ourselves until the objects are merged upstream in GTK+, and GNOME 3.0 wants these libgnome* dependencies removed anyway, so it's worth the maintainer effort.
Forgot to say that the patches here fix bug #582785 as well.
The patch to use the GAppInfo facilities instead of GnomeDesktopItem to launch the file manager introduces a regression. When the file manager is launched, it should run the command "nautilus --sm-disable --nodesktop --no-default-window". For reference, the original bug was 168990.
Thanks for the attached patches. Has anyone proposed EggSMClient for inclusion in gtk+? It would make more sense if we created patches for gtk+ that properly resolved bugs 79285 and 161483. Personally, I think this copying and pasting of EggSMClient code throughout GNOME is a poor solution for removing Gnome-Client. If EggSMClient is to be the replacement for Gnome-Client then it needs to be in a library, preferably gtk+. Reference bug 79285. For the most part, the same issue applies to the Gnome-Entry widget. I understand the widget is less used throughout GNOME, but are we are just going to deprecated it? It would be better to offer a replacement in gtk+. Reference bug 161483.
(In reply to comment #13) > Thanks for the attached patches. > > Has anyone proposed EggSMClient for inclusion in gtk+? It would make more > sense if we created patches for gtk+ that properly resolved bugs 79285 and > 161483. Of course everybody agrees here I guess, but it's once again a question of manpower, and bug 79285 does not seem to be ready for 2.28 it seems. I cross fingers for 3.0. Anyway I currently prefer for the short term to copy that code (though the idea is ugly) instead of keeping libgnome(ui) for a few pieces.
(In reply to comment #12) > The patch to use the GAppInfo facilities instead of GnomeDesktopItem to launch > the file manager introduces a regression. When the file manager is launched, > it should run the command "nautilus --sm-disable --nodesktop > --no-default-window". For reference, the original bug was 168990. I believe the reasons behind that original report don't stand anymore, as Gnopernicus is not used nowadays (it has been replaced by Orca) and magnification is done using the composite extension of the X server.
(In reply to comment #13) > Thanks for the attached patches. > > Has anyone proposed EggSMClient for inclusion in gtk+? It would make more > sense if we created patches for gtk+ that properly resolved bugs 79285 and > 161483. > > Personally, I think this copying and pasting of EggSMClient code throughout > GNOME is a poor solution for removing Gnome-Client. If EggSMClient is to be > the replacement for Gnome-Client then it needs to be in a library, preferably > gtk+. Reference bug 79285. > > For the most part, the same issue applies to the Gnome-Entry widget. I > understand the widget is less used throughout GNOME, but are we are just going > to deprecated it? It would be better to offer a replacement in gtk+. > Reference bug 161483. I am aware of those reports, but you will agree with me that the effort in fixing them properly is not comparable to the effort of copying and maintaining some files inside our own gnome-utils tree and writing these patches :) Basically every single application that used the session management from libgnome either dropped it (which is bad in some cases) or copy-pasted EggSMClient. When that will land in GTK+ proper (and I suppose/hope there are plans to do that soon rather than late, as many applications use it), we can drop our copy, and I can promise you I will write a patch for that :) I think things are a bit different for the history entry: both the libgnome and the current GEdit implementation uses GConf to save history, which is bad, as GTK+ doesn't depend on it. Ideally, that code should be rewritten to save to XML or a GKeyFile in ~/.config before being proposed for inclusion. As I already said, I agree that this is not the cleanest solution of the world, but it's a start, and something we will very likely need to do to be GNOME 3.0-compliant anyway.
Regarding comment #15... Thanks again for your patch. I did a little research, and I found "GDesktopAppInfo" from gio for replacing my use of the "GnomeDesktopItem" API. The issue I was referring to in comment #12 has nothing to do with Gnopernicus or Orca. The regression is that with your proposed patch when nautilus is launched it will manage or "take over" the desktop. Some people are not using nautilus for desktop management. For example, they may be using Thunar. So if nautilus is launched, the command line should contain the "--no-desktop" option to prevent nautilus from managing the desktop. I have copied the beginnings of a new patch using the GDesktopAppInfo API to the original bug 582785. Thanks.
Cosimo, The patch attached to comment #9 is missing the libegg/Makefile.am file.
Created attachment 134851 [details] [review] [build] Add libegg/Makefile.am
Here it is, I forgot to git-add it :)
Thanks Cosimo. I made some modifications to your patches and applied them to the HEAD branch of gnome-utils. As a result of these changes, the number of shared libraries required by gsearchtool has been reduced by 30% which is fantastic. Of course, I consider the use of libeggsmclient a temporary replacement for Gnome-Client. I am marking this bug report resolved for now, but please reopen when bugs 79285 and/or 161483 are resolved.