Dropbox integration with gnome nautilus 43.2.1 is no longer working. Your latest fix (nominal version 2022.12.05 Fedora 37) for gnome 43 is no longer working as well. about nautilus-dropbox HOT 5 CLOSED

I think it might be quite difficult to fix this in nautilus itself, unless they revert that commit.
For now, an easy fix is:

cd ~/.dropbox-dist/dropbox-*/images/emblems
mkdir -p hicolor/64x64/emblems && cp *.* $_

This basically sets up the correct folder structure for the emblems to be added to the fallback hicolor theme, so that nautilus will think they exist properly.

from nautilus-dropbox.

I have digged a bit deeper, and I think I have found the root cause. It's likely incorrect behavior on the part of nautilus, although Dropbox is also partially to blame for not putting the emblems inside the hicolor theme.

I have reported it here: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2789

from nautilus-dropbox.

With my workaround above, and with

Nautilus workaround: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1174
My GTK fix: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5865

I think this issue can be closed. Those fixes should eventually land in distros.

A quicker fix would be if Dropbox packages their emblems in the hicolor theme to begin with (like in my "fix" above), but I don't think that'll happen (@goffrie ?).

from nautilus-dropbox.

Same problem here. It seems to be related to the emblem path finding, because the "shared" emblem is still displayed (which is built-in?).

from nautilus-dropbox.

@velsinki Thanks for your work upstream. Indeed Nautilus 43.4 (which is now in Fedora 37 updates) includes your fix and resolves the issue.
For v176 of the client I'll move our emblems into hicolor as that appears to work on all Nautilus versions and seems "more correct" if I understand correctly.

Thanks everyone for your patience.

from nautilus-dropbox.