GTK+ Forums

Dear friends,
in my GTK(3) app, I am using icons as

or


The problem is, when I am running the app away from the source
directory, those images are broken, obviously due to the fact that the
path is missing. One solution is to put absolute path, but then the code
will not be portable.

Is there any better way of doing it?

On windows/ms-dos O.S. the path start with "\" but on linux start with "/". So to avoid this, I do not put path in my programs to make reference to a file and I avoid these symbols (inside path context) in a favor to portability.
The bad thing about this is that the file need be on the same path of executable. If the file are in other path, so I create a code to deal with this.
Including the files inside executable you can avoid this. The bad thing is if you like to change only one icon, so, recompile again is necessary.

Not sure if these words give you some light, the intention is to help.

Can you kindly show me how I can do this?
I tried:


and then make:

which gives error:

Hi,

objcopy is not what you are looking for as it is for copying object files and doing transformations on them and not for graphic files.

You are better off saving your graphic files in XPM format which is C compilable or using the utility application gdk-pixbuf-csource then converting these in your application using gdk_pixbuf_new_from_xpm_data () or gdk_pixbuf_new_from_inline ().


Note if your images are fairly large then this can become a bit of a memory hog.

The other option is to use absolute paths for your images. These should be set to where the images will be installed or configurable in some way. As noted by a previous poster avoid using the path separator '/' or '\' and use the Glib functions to build paths for you or provide two versions of the path. One for Unix based systems and one for Windows based systems.

_________________
E.

Like Sr errol have said;
I have used command below because I'm coding in other language.

After, I have made a hexdump in myoutput and after changed it a bit.

The generated file veryclose can be now inserted in my source code like a raw hex string.


And the pseudo-code is like this, pixbuf and aloalo are in this example, global variables, and "offset" means a pointer to that data:

Looking at the original posters code it looks like he is using C. Using pseudo assembly code is very hard to read and understand by the majority of people so it would be best to stay with using C when giving examples. Also C tends to be much more portable than assembly.

_________________
E.

file locations should never be embedded directly in code. You are right that it is not portable. It is also bad practice. At some point later you (or someone else) may rearrange where you are storing your files and things will break. The structure of your source package and the programming should be kept separate so that someone who tries to debug one doesn't require a full working knowledge of the other.
File locations should be handled by macros in the makefile. It will resolve OS dependent paths and provide checks the file exists where it should be at compile time (and provide fallback options if it doesn't). If you haven't used the autotools before then now is a good time to learn as this issue is one that they are designed to resolve and they do it very well.

Can you kindly be more elaborate? About the specific Macro I need to use?

e.g. if using the autotools in configure.ac you'd put something like:

which defines DLMT in config.h which if linked in can then allow you to use the DLMT macro throughout your program. In this eample I've used the different end of line characters for windows & unix likes, but you can define a variety of different macros this way. Tricky thing with absolute paths is that your program can install in different places and this needs to be taken into account (e.g. in linux it can often be either /usr/share/pixmaps or /usr/local/share/pixmaps).
In this case you'd use the autotools to define a macro to the installation directory and then in your program put it together in a portable way with glib functions. E.g. in one program I have:

which builds the path from a config.h maco and the particular filename (though it is a bit different as I've used another glib function within it).

However, for icons I've always used the gnome packagename.desktop file to identify icons for programs (I haven't tested this as to how it goes when ported to windows etc). It is set up in the Makefile.am with: