Re: What strategy to use to deal with Glade-3's problem in removing pixbuf directory paths in .glade file!

[Daniel Yek <dyek real com>]

Hi Tristan,

Thanks for responding. My responses inlined below...

Tristan Van Berkom wrote:
> On Mon, Oct 6, 2008 at 2:01 PM, Daniel Yek <dyek real com> wrote:
> > Hi,
> >
> > I'm trying to find a way to deal with the problem with Glade-3 removing
> > absolute or relative path from pixbuf property.
>
> Hi,
> since we are in the middle of adding builder support, this would be a
> great time to file a bug describing what would be the desired behavior
> for builder (patches also welcome ;-) )
>
> That being said, the rationale behind libglade style pixbufs is that
> the pixbuf is either in the working directory, 
> > o libglade is capable of supporting .glade-file-relative path. (Good.)

Not the arbitrary process current working directory, but the directory 
where the .glade XML file resides.

I, later, thought of a more viable solution: instead of moving the many 
graphics files to the .glade file directory, which is in the main binary 
directory in my case, I should move the .glade file into a subdirectory 
with graphic files.

> or in the specified pixbuf directory (you can add a search path with 
> the libglade api).
> > o gdk-pixbuf's gdk_pixbuf_new_from_file() requires absolute or 
> relative paths without resource resolution based on any environment 
> variables. So, application can't make libglade resolves resources by 
> setting an environment variable.

I seriously doubt it that application can add search path with libglade 
API, but I might be wrong. Could you kindly point out the API function 
to use?

libglade-2.6.2/glade/glade-xml.c
 glade_xml_set_value_from_string()
   case G_TYPE_OBJECT:
     if (G_VALUE_HOLDS(value, GDK_TYPE_PIXBUF))
     {
       ...
       filename = glade_xml_relative_file(xml, string);
       pixbuf = gdk_pixbuf_new_from_file(filename, &error);
       ...
     }

Thank you!

--
Daniel Yek.



> Glade 3 not allowing a full path is a shortcomming related to poor
> handling of external resources (i.e. pixbufs related to a glade file
> are tracked and copied with the glade file... poorly, also bug reports
> and patches welcome...)
>
> Cheers,
>            -Tristan
>
>
>   
> > That is, given a .glade file containing:
> > <widget class="GtkImage" id="image">
> >   <property name="pixbuf">relativepath/image.png</property>
> > </widget>
> >
> > Glade-3 would remove the path and generate this instead:
> > <widget class="GtkImage" id="image">
> >   <property name="pixbuf">image.png</property>
> > </widget>
> >
> > Isn't it that, in general, when dealing with XML, it is a good idea not to
> > regenerating everything, but to keep all XML tags/blocks that the
> > application/tool doesn't understand? This is desired!
> >
> > In this case, isn't it that Glade-3 shouldn't be discarding data (directory
> > paths) when that relevant tags/blocks in the xml file aren't even modified?
> >
> > The ideal case aside, is there a strategy to deal with the current,
> > following, situation?
> > o Glade-3 insists on removing directory path from pixbufs. (Problem.)
> > o libglade is capable of supporting .glade-file-relative path. (Good.)
> > o gdk-pixbuf's gdk_pixbuf_new_from_file() requires absolute or relative
> > paths without resource resolution based on any environment variables. So,
> > application can't make libglade resolves resources by setting an environment
> > variable.
> >
> > Note that if Glade-3 were to not discard relative paths from pixbuf in
> > .glade file, libglade would have worked.
> >
> > I think one clumsy way I can deal with this is to create a script that
> > post-process .glade file touched by Glade-3 to explicitly restore the pixbuf
> > directory paths.
> >
> > Is there another better way to deal with this problem?
> >
> > Thanks.
> >
> > --
> > Daniel Yek.
> >