After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 126328 - updating gdk-pixbuf.loaders should be simpler
updating gdk-pixbuf.loaders should be simpler
Status: RESOLVED DUPLICATE of bug 129540
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 121667 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-11-06 00:25 UTC by Benjamin Otte (Company)
Modified: 2010-07-10 04:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Benjamin Otte (Company) 2003-11-06 00:25:44 UTC
Currently there is no simple way to update gdk-pixbuf.loaders, every
program that installs loaders that I know does it wrong and fails updating
the loaders in some cases.

My suggestion would be to add a command-line option to gtk-query-loaders
that doesn't print to stdout but updates the right gdk-pixbuf.loaders file
instead.

I'll volunteer to write a patch.
Comment 1 Matthias Clasen 2003-11-06 08:00:57 UTC
Sounds like a good idea to me. Note that gtk-query-loaders was modeled 
closely after pango-query-modules, so if its a good idea here, it may 
apply there too.
Comment 2 Tor Lillqvist 2003-11-07 02:29:05 UTC
Wouldn't the cleanest solution be to have a directory, 
$prefix/etc/gtk-2.0/gdk-pixbuf.loaders.d, in which there could be 
files, each file describing one 3rd-party pixbuf loader? GTK would in 
addition to reading the current gdk-pixbuf.loaders file, read files 
there might be in this directory. A 3rd-party loader would then only 
have to install one file in this directory.

Only files with names matching some pattern (*.loader, or whatever) 
should probably be handled, to avoid editor backup files etc.
Comment 3 Benjamin Otte (Company) 2003-11-07 15:16:07 UTC
The problem is that there needs to be a way to find out the correct
directory.
Debian for example installs config info into /etc/gtk-2.0/ while gtk
is installed in /usr and there needs to be a way to figure this out
when installing loaders and updating the config file.

You're correct though that my idea wouldn't have fixed the problem as
I still wouldn't know where to install the loader.

Maybe some additional .pc file information on where to put modules
and/or the config file?
Comment 4 Matthias Clasen 2003-11-09 23:30:50 UTC
Well, gdk-pixbuf-query-loaders is linked against gdk-pixbuf, so you
could use gdk_pixbuf_get_module_file() to figure out what file
gdk-pixbuf will read, *if* that function wasn't static. We should
export that function, and add a cmdline arg --update or similar to
gdk-pixbuf-query-loaders which would make it write to the file instead
of stdout.
Comment 5 Benjamin Otte (Company) 2003-11-11 01:59:52 UTC
Yeah, that would solve the problem of needing to know the loaders file

However, this still doesn't solve the problem that you need to know
PIXBUF_LIBDIR in your app, too.
Comment 6 Matthias Clasen 2003-11-11 07:59:24 UTC
You mean you need to know it in the makefile in order to install the 
modules ?


I guess we could add another cmdline argument, like --loaderdir,


which would make gdk_pixbuf_query_loaders write out the directory


in which it looks for modules, and exit.


Comment 7 Matthias Clasen 2004-02-02 09:53:14 UTC
Defining a few variables in the .pc file may be simpler
Comment 8 Owen Taylor 2004-02-02 17:38:29 UTC
I added a bunch of information about multi-arch problems and
a proposed solution to bug 129540.
Comment 9 Owen Taylor 2004-02-24 22:10:55 UTC
*** Bug 121667 has been marked as a duplicate of this bug. ***
Comment 10 Owen Taylor 2004-02-24 22:49:21 UTC
Collecting all these bugs in one place

*** This bug has been marked as a duplicate of 129540 ***