The Directory Menu uses gtk_image_set_from_icon_name()[1] to set the icon, so it needs to be an icon from the icon theme to work - custom icons not supported.
As a workaround, you can copy your custom icon to ~/.icons (create the folder if it doesn't exist) and then you can find the icon under the "Uncategorized" or "All" sections.
It seems to me that it's a regression since it was possible to use custom images in the previous version.
Moreover, the system allows me to pick a custom image (as seen in attached screenshots), it's just that it has no effects when I validate (with no warning nor alert message).
xfce_panel_image_set_from_source was replaced by gtk_image_set_from_icon_name. The former accepts a "source " which "can be an absolute path or an icon-name" according to the docs.
Well it seems that there's an issue somewhere, but I don't know if it's related to gtk_image_set_from_icon_name or to the way XFCE sends parameters to the method.
In my xfce4-panel.xml, I do have the following
where /home/xxx/Applications/Applis AMUE/LogoAMUE.png is a valid existing absolute path to a png image.
If I copy the icon to /usr/share/pixmaps then I can use it as an "uncategorized icon", but it requires privileges to copy files there (so it's still a regression, in my opinion).
I wonder if the problem could be in the property name "icon-name", maybe it should be a "button-icon"?
If I copy the icon to /usr/share/pixmaps then I can use it as an
"uncategorized icon", but it requires privileges to copy files there (so
it's still a regression, in my opinion).
To avoid the need to copy to system directory, you can use xdg-icon-resource to install icon resource in your homedir. I did it like that:
(where 48 is size of the icon, you can choose whatever size suits you).
In my case icon gets installed inside ~/.local/share/icons/hicolor/48x48/apps/, so no system permissions are necessary. Icon installed that way can be easily selected as directorymenu plugin icon and is visible under "Application icons" (actually I found this solution just to do that).
A quick note to say that this affects other parts of Xfce as well - for example Thunar Custom actions. Can't display custom icons anymore. Copying them to ~/.icons will also work (will show up under uncategorized).
Yes, I'm seeing the same problem with UCA. This problem is not reproducible with Launchers because exo is a bit more smart and checks if the selected icon is an absolute path.
My idea is to introduce a function in libxfce4ui (e.g. xfce_gtk_image_new_from_source) and use it in directory-menu and UCA (and elsewhere needed). @ochosi what do you think?
The panel also has a function similar to exo, but I stopped using it because it only relied on pixbufs instead of icon names.
So yes, one generic clever function in one of our libraries would be appreciated!
Please see this draft, besides the inelegant API, there are two bugs I couldn't fix:
When both the panel and plugin initialize, the panel width is for some reason reported as 16px by xfce_panel_plugin_get_icon_size, the icon is loaded with size=12px, only after initialization is that that function returns the panel's correct width.
When an icon is selected in the plugin's property dialog, the icon button is not updated.
Note that xfce_panel_pixbuf_from_source() already exists and does the main work. So adding a xfce_panel_set_image_from_source() wrapper here might also work.
But I don't know if it's worth it. Taking example on what is done for the appmenu could be enough. I think I'll move in that direction in the next few days, probably making some small fixes to xfce_panel_pixbuf_from_source_at_size(), by the way.
It can always be transported to one of our shared libraries afterwards, if desired.