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 768854 - Improper loading of GtkImage by file name from another directory
Improper loading of GtkImage by file name from another directory
Product: glade
Classification: Applications
Component: general
Other Linux
: Normal minor
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
Depends on:
Reported: 2016-07-15 18:54 UTC by Matthieu Vigne
Modified: 2018-03-26 15:55 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Matthieu Vigne 2016-07-15 18:54:55 UTC
Create a new Glade project, put a GtkImage in it, ask to load image by file name. Load an image from a directory other than the one in which the Glade file is. Glade does not add relative path to the image name and doesn't load the image (this may be intentional behaviour to prevent user from using images in another directory?). If you add the relative path by hand, Glade still doesn't load the image, but when Gtk starts it runs fine.

Now create a second image, load by file name and select another image file from another directory. Go back to the first image: the file name is now the same as the other image. This happens with any number of GtkImage: in other words, all GtkImage pointing towards an image file in another directory will point towards the same image file.
By editing the Glade file by hand, one can make it such that the images are loaded fine by the Gtk application. But as soon as Glade opens the file, it will replace all the images from another directory with the last one read.
Comment 1 GNOME Infrastructure Team 2018-03-26 15:55:23 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: