Can you please attach a glade file that has this problem ?

Also, is the image not displayed while editing the file in Glade or does it not exist when using the glade file with GtkBuilder and actually running the application ?

If I recall correctly, GtkBuilder loads files from the same directory as the file loaded with gtk_builder_add_from_file() (if _add_from_file() was used), otherwise it falls back on the current working directory.

It may turn out that we need to add some feature to GTK+'s GtkBuilder to make the loading of external resources (as files or GResource paths) more fool proof and usable.

The logo (either SVG, JPG or PNG) is shown inside the design-window if I put the files in the same directory as the glade file. Both are not shown in the window-preview.

Putting the files in a subfolder results in both images not working. They are not shown inside the design-window and not in the window-preview.

I bet that if you start 'glade' from the command line, in the same directory that the image files are located, then the preview will see them.

This is a sticky issue, there are some lacking features in GtkBuilder to make this work properly, in any case we will have to verify if GtkBuilder can indeed be told from which directory to load resource files, and if not, we will have to teach GtkBuilder to understand that before we can properly close this bug.

Just starting Glade from the command line produces this error in Ubuntu 14.04. Not sure if it is relevant:

GladeUI-Message: 1 missing displayable value for GtkCellRendererAccel::accel-mode
GladeUI-Message: Glade needs artwork; a default icon will be used for the following classes:
	GtkApplicationWindow	needs an icon named 'widget-gtk-applicationwindow'

Created attachment 274714 [details] [review]
Proposed patch

There are two problems here

First GladeAboutDialog editor sets "logo-icon-name" to NULL instead of its default value "image-missing" this makes Glade save an empty bogus "logo-icon-name" property.
This makes the "logo" property unusable with GtkBuilder since the image will always be overridden by "logo-icon-name"

Second in glade_widget_adaptor_object_read_widget() we sync every property that is not present in the UI xml definition, so even if you only specify a "logo" property the image will be overridden in the workspace.

Tristan do we still need to sync properties in glade_widget_adaptor_object_read_widget()?

(In reply to comment #5)
> Tristan do we still need to sync properties in
> glade_widget_adaptor_object_read_widget()?

This is a hard question, I can say at least that changing that behaviour falls under the most dangerous category of changes to make in Glade.

Glade has always had a zero-tollerance policy about questionable property values, the property values which exist that are questionable have special case attributes specified for them in the catalog.

This means that in some cases a property can be "ignore" or "save-always" or such to deal with mis-behaving properties and special cases, but for everything else the rule must hold that an introspected or default value can be set on the runtime instance without being destructive.

This means that:
  if g_object_get() returned "Hello World" for the text property of a label,
  then setting "Hello World" on that property is the correct course of action.

By the same rights, it means that:
  if g_object_get() returned NULL for the "logo" property of an about dialog,
  then setting NULL for the logo property is the correct thing to do.

In Glade we do not have the luxury of a typical GObject life cycle, there is no concept of "well I didnt set this property YET, so it should remain UNCHANGED", there is no such thing as UNCHANGED... Glade must be able to produce a runtime object for the workspace at ANY time based on the current property values in Glade's project data model.

What we do have as a special case for this kind of problem is the concept of "optional" properties, the "optional" properties are indeed never set on the runtime object unless the property is considered "enabled" in Glade's data model, and Glade infers which property was "enabled" for an optional property based on whether it was mentioned in the glade project that was loaded.

What would work for this case might be something like this:

  a.) Mark the icon related properties of the about dialog as "optional"

  b.) At load time, ensure that only one option is enabled

  c.) Use a radio button in the about dialog editor to control which option 
      is currently "enabled" and only allow modifying the value of an enabled
      property (making the other properties insensitive).

This way the editor can dictate which of the "optional" properties are "enabled"

Yeah I know its dangerous, it might help for this but I am pretty sure it would break ten other things.

BTW I think we should include these remarks somewhere in the docs :)

So yeah marking those props optional is the way to go and now that I see we can disable the checkbutton (since its going to be controlled by the radio button) I like it even more

Fixed in master and glade-3-18 branch