caja does not read icon data

[ghost]

seams like caja isn't reading icon data on the gtk3 port(eg translations of icons/emblems, and attach points for the embed test/text preview)

• See also Table3 Icon Data Keys

LANG=C apt-cache show caja   
Package: caja
Version: 1.16.1-1
Installed-Size: 3185
Maintainer: MATE Packaging Team <pkg-mate-team@lists.alioth.debian.org>
Architecture: amd64
Depends: caja-common (= 1.16.1-1), desktop-file-utils, gvfs, libcaja-extension1 (= 1.16.1-1), libglib2.0-data, mate-desktop, shared-mime-info, libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo-gobject2 (>= 1.10.0), libcairo2 (>= 1.10.0), libexempi3 (>= 2.3.0), libexif12 (>= 0.6.21-1~), libgail-3-0 (>= 3.0.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.41.1), libgtk-3-0 (>= 3.21.4), libice6 (>= 1:1.0.0), libmate-desktop-2-17 (>= 1.14.0), libpango-1.0-0 (>= 1.20.0), libpangocairo-1.0-0 (>= 1.14.0), libselinux1 (>= 1.32), libsm6, libstartup-notification0 (>= 0.2), libunique-3.0-0 (>= 2.90.1), libx11-6, libxext6, libxml2 (>= 2.7.4), libxrender1
Recommends: gvfs-backends
Suggests: engrampa, gstreamer1.0-tools, meld
Breaks: libcaja-extension (<< 1.10.0), libcaja-extension1 (<< 1.10.0), mate-session-manager (<< 1.8.1-7)
Description-en: file manager for the MATE desktop
 Caja is the official file manager for the MATE desktop. It allows one
 to browse directories, preview files and launch applications associated
 with them. It is also responsible for handling the icons on the MATE
 desktop. It works on local and remote filesystems.
Description-md5: 2d27e6d6f085ec92e7532bd116bd9d0a
Multi-Arch: foreign
Homepage: http://www.mate-desktop.org/
Tag: interface::graphical, uitoolkit::gtk
Section: utils
Priority: optional
Filename: pool/main/c/caja/caja_1.16.1-1_amd64.deb
Size: 802896
MD5sum: 489b795667e2bfa87af1f54f45cdde70
SHA256: 51b28dcfc59f40da8d80a2097e5499eba7009122e56f4e4c02fbdf5f7e918432

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/40581704-caja-does-not-read-icon-data?utm_campaign=plugin&utm_content=tracker%2F651521&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F651521&utm_medium=issues&utm_source=github).

[marcxjo]

The latest Nautilus and Nemo don't seem to read attach points at all from .icon files. Modifying attach points and updating the respective icon caches doesn't change the emblem positions in either of them in Fedora 25+. Was this feature possibly dependent on a GTK+2 function that was never ported to GTK+3?

In any case, a good workaround for the time being would be to hard-code sane attach points, say, at the four corners of the icon. This is obviously not a huge problem, but it's ugly and annoying, so I'd love to see some work on this.

My C sucks, so I could try, but it'd likely take an annoyingly long time for something so simple.

[marcxjo]

I'm at a loss on this. Rifling through the GTK+3 git logs, I thought it might have to do with the fact that gtk_icon_info_get_attach_points () and several other bits of icon theme API were wiped out over a year ago (see https://gitlab.gnome.org/GNOME/gtk/commit/d18891233839db96478d8765425c9e390fa9c7ef), but that doesn't actually seem to affect the 3.22 branch.

I've looked at several other similarly deprecated functions and features that didn't make it to GTK+3 from GTK+2, and they all seem to be dealt with, like the use of cairo_t in place of missing Gdk types, etc. Basically, I'm in over my head for the time being, because I can't find the reason this doesn't just work.

Would love to see someone with actual C experience take a crack at this, though.

[lukefromdc]

GNOME is always removing features they no longer use, probably to avoid maintaining stuff they won't ever see in their default use case. When this affects GTK itself though, it creates headaches for a lot of projects.

[marcxjo]

Sure, they're definitely notorious for this, but for the time being, the function I'm talking about is actually still available even in the latest GTK+3.22 branches. It's been removed in master, which afaict is currently being prepped for the first GTK+4 release.

I don't know where the issue is with Caja failing to read icon data as a result of that. We'll surely know the root of the problem when it's time to port to GTK+4, though... X-<

[WGRM]

This bug should be posted again, since it hasn't gotten any attention from any developer. I need this everlasting bug fixed. I want to write extensions for Caja, which will add emblems corresponding to other conditions. Pretty nifty to have.

I couldn't approach the problem from the source view of things. I downloaded other distributions and searched the internet. All examples and the specification state, that my "Icon Data" file is correct. Although i would be strictly against removing the functionality of "Icon Data", the workaround, to hard code the placing of the emblems, would sufficient. At least for now.

Caja already has the amount of icons hard coded:

Columns: 1: View size 2: Amount of icons per side 3: Displayed correctly 4: The total amount of space for icons 33% 2 y 4:x,y|x,y|x,y|x,y 50% 2 y 4:x,y|x,y|x,y|x,y 66% 3 n 8:x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y 100% 3 n 8:x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y (should be 48px) 150% 3 n 8:x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y 200% 3 n 8:x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y 400% 5 n 16x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y|x,y

So, Caja displays emblems correct, as long as the amount doesn't exceed 4. This is true for 33% and 50%. If your view is 100%, Caja tries to place 3 icons per side and from there on, every second emblem is placed wrong. Try it. The position for the second emblem must have any kind of mistake and it seems to be some kind of generic function. That is because the same mistake happens for every side.

How can i push this bug report?