New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XDG icon specs implementation woes: Introduction to the missing icons #908
Comments
I tried to stay out of this as much as possible... Of course I'm all for "let's merge this into a single implementation". I'm not sure what's the best course of action here. Perhaps @actionless can say something? |
i wasn't really looking too much into desktop files parsing thing, mostly on multipage rendering, so unfortunately i don't have any strong opinion on that, but in general yes, it's usually better to generalize things, so i am voting up for merging that logic somehow together |
Indeed, there are some nofitication clients known to request an icon by name. nm-applet for example requests its icons by their short name ( Here is a test case regarding that nm-applet icon for all three implementations. $ find /usr/share/icons/ -name 'nm-device-wired*'
/usr/share/icons/gnome/16x16/status/nm-device-wired.png
/usr/share/icons/gnome/22x22/status/nm-device-wired.png
/usr/share/icons/gnome/24x24/status/nm-device-wired.png
/usr/share/icons/gnome/256x256/status/nm-device-wired.png
/usr/share/icons/gnome/32x32/status/nm-device-wired.png
/usr/share/icons/gnome/48x48/status/nm-device-wired.png
/usr/share/icons/hicolor/16x16/apps/nm-device-wired.png
/usr/share/icons/hicolor/22x22/apps/nm-device-wired.png
/usr/share/icons/hicolor/32x32/apps/nm-device-wired.png
/usr/share/icons/hicolor/scalable/apps/nm-device-wired.svg A test program (run it e.g. within vim as local naughty = require("naughty")
local menubar_icon_theme = require("menubar.icon_theme")
local menubar_utils = require("menubar.utils")
local awful_util = require("awful.util")
naughty.notify({
title = "Version 1/3",
text = "Calling menubar.icon_theme():find_icon_path() ... ",
icon = menubar_icon_theme():find_icon_path("nm-device-wired"),
timeout = 0
})
naughty.notify({
title = "Version 2/3",
text = "Calling menubar.utils.lookup_icon() ...",
icon = menubar_utils.lookup_icon("nm-device-wired"),
timeout = 0
})
naughty.notify({
title = "Version 3/3",
text = "Calling awful.util.geticonpath() ...",
icon = awful_util.geticonpath("nm-device-wired"),
timeout = 0
}) Apparently the awful.util implemenation has failed to find anything at all. That's way the popup in #899 has no shiny icon when I plug an RJ45 in while it is actually supposed to be there. |
Just a quick note that I personally use GTK/GDK for this. I know @psychon wont allow a dependency on GTK because it cannot be trusted not to implement new features that might accidently deaklock Awesome when requiring GTK, but it give a very fast, asynchronous and compliant implementation. As a big plus, it also support thumbnails. https://github.com/Elv13/awesome-configs/blob/master/utils/fd_async.lua#L410 |
If it's so slow (can't check right now and noone here provided benchmarks) than maybe it's better to use C for icons lookup? |
It's not slow because of Lua, it is slow because of all the I/O operations and inodes checks. KDE, for example, keep a service with some SHM memory to share this burden across all applications. I am not sure how GTK/GDK handle this, but they probably have some caching too. |
@osleg: I'm sorry, there are no real benchmarks ATM, it is merely my personal opinion. I have been using the patched menubar which uses As a sidenote regarding the language: I believe the verbatim implementation of the algorithm from the standard text (like the |
@Elv13: Thanks for the heads up, I'm going try first that external implementation and see if it works for me. It probably could serve us as a good reference. |
Sigh. Apparently we'll have to use GTK for this. This bug provides a good reason and my unspecific fear that something might go wrong is weaker than that... If someone wants, feel free to make awesome use GTK. How/where do we call |
also i remember you were mentioning what we can use some gtk function to have resizeable svg-s |
No... please don't, that's not a bug but slow and quite unreliable
implementation which might be implemented without adding dependencies.
Especially adding GTK as dep will break the idea of lightweight WM
dependant on xcb (iirc) only :'(
|
@osleg Sorry, but Awesome already depends on cairo, pango, gdk-pixbuf, xcb, xkbcommon, startup-notification, lua, xdg-basedir, dbus, glib and some other stuff. Also, I don't think that loading libgtk automatically makes something not-lightweight. |
ah, right, i found that discussion: #390 (comment) |
@psychon, adding a non-lightweight toolkit making it non-light weight. The issue is:
So basically all is required is to write an icon fetcher with cacher.... I know that's not a five minute task, but wouldn't it be better to add this functionality only instead of pulling an entire toolkit just for that? |
are you able to run awesome without gtk? UPD: my bad, lgi don't require it |
$ apt-cache depends awesome And I actually do it on RasPi |
is anybody going to take the decision which implementation of icon path routine to leave? from this screenshot it seems what at least unless awesome support SVG scaling i would suggest modifying iconpath function to also receive "desired_size" argument and choose the icon which is the same or closest (but bigger) to the requested size and if that arg is not set then use some |
Currently: No, doesn't look like it. Ultimately it does not really matter which of the routines is used, it only matters that only one remains and that it is standards compliant. I guess it should then end up being in
Depends on what level of SVG support you want. "Load this SVG into a surface of size |
i think if we would be able to do the first the we can implement the latter with some special type of widget. which will be reloading svg each time when widget geometry changes |
Just if you want something to play with: local lgi = require("lgi")
local GdkPixbuf = lgi.GdkPixbuf
local Gdk = lgi.Gdk
Gdk.init({}) -- Sigh :-(
local file = "/usr/share/weston/wayland.svg"
local _, width, height = GdkPixbuf.Pixbuf.get_file_info(file)
print("Native size is", width, height)
local surface = Gdk.cairo_surface_create_from_pixbuf(GdkPixbuf.Pixbuf.new_from_file_at_size(file, 300, 300), 1, nil)
print(surface, surface.status) Edit: Nice, last time I looked this was harder to do. |
Also, note that librsvg needs to be installed or bad things will happen |
"Bad things" being GdkPixbuf telling you that it does not support the file format? |
I have seen crashes in the past in some GTK apps, but the apps were probably to blame. The autogen often forget to check for librsvg because it is implicit and Gentoo doesn't install it unless there is a dependency or an USE flag. So this is a common issue for Gentoo users. So "bad things" is "if you don't handle it, then it will eventually print a |
Since this was mentioned in #1549, I took a look over the three: Currently -- This implementation is based on the specifications:
-- Icon Theme Specification 0.12
-- http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-0.12.html It does have some caching based on the theme name and the directories searched. There might be some room for improvement, but it's good.
I'm for going only to the freedesktop standard (since it is a standard after). |
Unfortunately, it only considers non-scalable icon sizes like 32x32, 48x48, 64x64 etc., while naughty itself has no trouble with displaying SVG icons. I tested it with Does this count as a separate feature request or is it a part of this issue? |
Judging by those parts of the Lua code which I have already got myself acquainted with, you maintain at least 3 (three!) competing facilities to map the icon names (possibly along with its screen size) into the file names on a disk. Let's introduce our players briefly:
icon_theme.find_icon_path()
of lib/menubar/icon_theme.lua. Used solely to extract 10 (ten) paths to the categories icons (Office, Development, etc) in the menubar.utils.lookup_icon()
of lib/menubar/utils.lua. Used by the menubar implementation to extract the vast majority of application icons set in their respective *.desktop files.util.geticonpath()
of lib/awful/util.lua. Used by the naughty module to extract the full icon path using the icon name being received from a notification client over DBus.They all three do work differently. Even worse they all three fail differently. This results in some application icons missing from the menubar and the icon missing from the notifications popup sent over DBus. I've tried switching them back and forth (using the menubar as a guinea pig) and from the three of those
icon_theme.find_icon_path()
being the most sophisticated seems to be a noticeable favorite as well. It was able to find most of the icons (with or without icon theme set in beautiful) compared toutils.lookup_icon()
, albeit there are failures too (e.g. "nvidia-settings.png" - note the extension - could not be found while it is happily sitting under /usr/share/pixmaps).Given that bestiary the real question reveals: is it worth to propose fixes for individual issues or is there already some undergoing black op plan of merging them/dropping them/adding 4th to the party/etc? From my personal point of view adding all the corner cases handling to the
icon_theme.find_icon_path()
and dropping (deprecating) the rest of a company would be the preferable and cleanest path but that might render a new problem - it is inherently slow. Recent making of the menubar asynchronous can mitigate it for some degree though.Just in case you prefer leaving it all as it is I can open an issue for each and every missing icon I have, possibly along with a "fix".
The text was updated successfully, but these errors were encountered: