Gtkdialog - How to find/set path for icons?

[MochiMoppel]

It seems that gtkdialog does not recognize full icon paths for its tree widget. I can only provide an icon name, but how does gtkdialog determine the path for such an icon? Let's say I create a tree like this:

Code: Select all

echo -n '
<tree>
	<item icon-name="opera">Browser</item>
</tree>' | gtkdialog -s

Is there a way to tell gtkdialog where to look for the "opera" icon? Through trial & error I found that gtkdialog searches following directories - in this bizarre order:
/usr/share/icons
/usr/local/lib/X11/mini-icons
/usr/share/pixmaps

There might be more, but any other directory I tried didn't work. So where are these icon paths defined? Can I add my own?

[SFR]

Icons and themes are looked for in a set of directories. By default, apps should look in $HOME/.icons (for backwards compatibility), in $XDG_DATA_DIRS/icons and in /usr/share/pixmaps (in that order).

Code: Select all

# echo $XDG_DATA_DIRS
/usr/share:/usr/local/share
# 

The only way to add your own location I know is to add it to XDG_DATA_DIRS, e.g.:

Code: Select all

#!/bin/sh

TMPICONS=/tmp/Temporary_Icons
mkdir -p "${TMPICONS}/pixmaps"

echo '<svg>
  <rect height="48" width="64" fill="white" />
  <circle cx="32" cy="24" r="16" fill="red" />
</svg>' > "${TMPICONS}/pixmaps/Flag.svg"

export XDG_DATA_DIRS="${TMPICONS}:${XDG_DATA_DIRS}"

echo '<tree><item icon-name="Flag">Nissh

[MochiMoppel]

Thanks for your quick answer - and thanks for the hinomaru

I didn't know about $XDG_DATA_DIRS. Now everything starts to make sense.

The only way to add your own location I know is to add it to XDG_DATA_DIRS,

But what is odd is that the added path doesn't get priority, even if you put it in front of the existing path. No matter what I do, if there is a "Flag" icon in one of the default locations, the "Flag" icon in my newly added directory is not recognized.

This leaves $HOME/.icons as the most reliable location. Prevents conflicts with identically named images. Funny though: I tried to temporarily assign a different path to $HOME and then use $HOME/.icons, but this didn't work.

[SFR]

But what is odd is that the added path doesn't get priority, even if you put it in front of the existing path. No matter what I do, if there is a "Flag" icon in one of the default locations, the "Flag" icon in my newly added directory is not recognized.

Hmm, indeed...but only if I use .png extension in /usr/share/pixmaps/Flag.png.
If I use .svg (or .xpm) there instead, then /tmp/../pixmaps/Flag.svg takes precedence, as supposed to.
Or the other way around - use .png extension in /tmp/../pixmaps/Flag.png for the same effect.

So, looks like it also depends on alphabetical order of extensions: png > svg > xpm.

Well, I think the best way to enforce the precedence is to always use .png extension.

Greetings!

[MochiMoppel]

If I use .svg (or .xpm) there instead, then /tmp/../pixmaps/Flag.svg takes precedence, as supposed to.

Really? Not for me. I copied your file to /usr/share/icons/Flag.svg, made it green to see the difference. It takes precedence over /tmp/../pixmaps/Flag.svg. Same with .png files. Identically named files in /tmp.. and /usr.. will always result in precedence for files in /usr...

[SFR]

/usr/share/icons/Flag.svg

Oh, I was only testing /usr/share/pixmaps vs. /tmp/../pixmaps.
Yep, I can reproduce it.

Looks like 'icons' dir has precedence over 'pixmaps' - if you use /tmp/../icons instead of /tmp/../pixmaps, the proper one gets displayed.

But that's not all - turns out that icons/hicolor has even higher precedence, so if you put the green icon in e.g. /usr/share/icons/hicolor/scalable/apps/Flag.svg, it will again be displayed first...unless you'll put the original icon in /tmp/../icons/hicolor/scalable/apps/Flag.svg.
Nice, huh?

Greetings!

[MochiMoppel]

turns out that icons/hicolor has even higher precedence

As far as I understand the linked spec /hicolor is theme related, so it would be natural that those icons supersede the default icons

, so if you put the green icon in e.g. /usr/share/icons/hicolor/scalable/apps/Flag.svg, it will again be displayed first

Unfortunately not. I can display existing /hicolor... icons, but when I add new or just rename existing icons they are not recognized. Your system might work this way, but mine doesn't. Tried with a pristine slacko ... no luck.. It seems as if /hicolor icons are kept in memory cache. Anyway, /hicolor doesn't work for me

Nice, huh?

Do you want me to answer that?

I'm still wondering why a redefined $HOME doesn't work. Also kept in cache?
Well, I probably shouldn't wonder about anything in GTK anymore. My result of all this tinkering: The safest way is to put icons into the $XDG_DATA_DIRS path and make sure that they are named uniquely. MoppelFlag.png, MoppelStart.svg, MoppelCancel.png...something along this line

[step]

I'm writing from my phone so I'll be scant. The way findnrun 2.x.x manages to display all icons is by conducting its own search according to the spec and linking all icons it finds into a separate dir with troublesome icons renamed. It then adds that dir to XDG_DATA_DIRS and invokes gtkdialog. Without such gyrations there's always some corner case where an icon may be missing, this is my experience.

[recobayu]

This is the answer of my old question there:
http://murga-linux.com/puppy/viewtopic. ... 0ae#863376
Hint for arbitrary location.
Thank you All..

[step]

This is the answer of my old question there:
http://murga-linux.com/puppy/viewtopic. ... 0ae#863376
Hint for arbitrary location.
Thank you All..

Hi, I'm not sure if you're asking a new question. Are you?

[recobayu]

Sure..
I implemented on my mukstart here:
http://murga-linux.com/puppy/viewtopic. ... 927#912927
Now supported icon in tree.
Thank you All. This is very nice thread.