IIRC the FDO notification spec states that the icon may be either an absolute path or an icon theme name. We already handle absolute path and can keep that logic (ie, only hand over the icon name to libsfdo if it's not an absolute path).

In reading the following paragraphs, please bear in mind that I am a layperson so I may have grossly misunderstood the code I read. I apologize in advance for that and welcome corrections.

In sway/swaybar/tray/icon.c, at the moment:

char *find_icon(list_t *themes, list_t *basedirs, char *name, int size,
		char *theme, int *min_size, int *max_size) {
	// TODO https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#implementation_notes
	char *icon = NULL;
	if (theme) {
		icon = find_icon_with_theme(basedirs, themes, name, size, theme,
				min_size, max_size);
	}
	if (!icon && !(theme && strcmp(theme, "Hicolor") == 0)) {
		icon = find_icon_with_theme(basedirs, themes, name, size, "Hicolor",
				min_size, max_size);
	}
	if (!icon) {
		icon = find_fallback_icon(basedirs, name, min_size, max_size);
	}
	return icon;
}

None of these functions test for existence or load from unrestricted, non-XDG paths such as /usr/share/m17n/icons. The fallback case iterates over well-known directories previously populated in basedirs. An absolute icon path is neither tested for nor ever correctly tried for existence in find_fallback_icon since in find_icon_in_subdir a basedir is always prepended, and as best as I can understand / is not one of the basedirs.

As unfortunate as this is for fcitx-m17n users like me, swaybar's current behavior appears to be compliant in that the specification has no provision for icon names independent of themes. It has advice on how to name, organize, and locate icon files within themes while being completely silent on free-standing icon files.

Regarding a move to libsfdo, a reading of its icon lookup code seems to indicate that it concerns itself only with efficiently loading icon themes. While it handles important aspects missing from swaybar's current handling of icons, such as icon caching, it does not seem to handle absolute paths at all.

The only compositor (and the only Arch Linux official package) I could find that currently uses libsfdo is labwc. Which, due to the strictness of libsfdo, has to work around it for both cases of icons specified as absolute paths and icon entries in .desktop files which specify a suffix/extension. My understanding is that if swaybar chooses to delegate all of its tray icon handling to libsfdo there will be no room for icons specified as absolute paths, unless swaybar itself starts working around its own design choice of standardizing on libsfdo.

swaybar: replace icon lookup with libsfdo #8607

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions