Make icons configurable

[DanielVoogsgerd]

A little overview what I'd like to do:

• [x] Change account tables to array of tables
• [ ] Implement icon lookup spec
• [ ] Make icons configurable

Fixes: #6

[DanielVoogsgerd]

I'm quite confused about the icon logic in general right now. I suspected that the icons would be updated if a new email is received, but looking at the code I only see the icons being set at initialization.

Besides that I'm considering what to do in the case no icons are defined. We can just run de daemon without the tray icon as it's not needed for the notification part of the application. We can incrementally fall back from new icon to unread icon to connected icon. Or the application has failed and a panic is appropriate (not my preference).

Any opinions on the matter?

[jonhoo]

Ah, so, the icons are changed by the loop towards the bottom which receives a message whenever the number of unseen messages changes!

The Icon Naming Spec suggests that we should be using status/mail-unread, status/mail-read, and probably status/network-transmit-receive. Judging from the FreeDesktop Icon Spec:

Implementations are required to look in the "hicolor" theme if an icon was not found in the current theme.

Unfortunately, hicolor seems to (at least on my machine) contain only application icons and nothing else, which isn't really a reasonable default. There's also a theme called default, but it's empty...

Unless we want to implement the full logic for choosing an icon, we'll have to do use some kind of heuristic. I'd suggest defaulting to the files in /usr/share/icons/oxygen/base/32x32/status/, since the oxygen icon theme seems to be pretty widely available. Thoughts?

I'd say that if any of the chosen icons are not available (which we should check immediately upon start), we should exit with an error.

[DanielVoogsgerd]

Ah, so, the icons are changed by the loop towards the bottom which receives a message whenever the number of unseen messages changes!

Oh that is so obvious now. Did not know Rust could use a for-loop in such a blocking manner. Cool!

The Icon Naming Spec suggests that we should be using status/mail-unread, status/mail-read, and probably status/network-transmit-receive. Judging from the FreeDesktop Icon Spec:

Implementations are required to look in the "hicolor" theme if an icon was not found in the current theme.

Cool! I could have guessed that there was a spec for this.

Unfortunately, hicolor seems to (at least on my machine) contain only application icons and nothing else, which isn't really a reasonable default. There's also a theme called default, but it's empty... Unless we want to implement the full logic for choosing an icon, we'll have to do use some kind of heuristic. I'd suggest defaulting to the files in /usr/share/icons/oxygen/base/32x32/status/, since the oxygen icon theme seems to be pretty widely available. Thoughts?

I'd say that if any of the chosen icons are not available (which we should check immediately upon start), we should exit with an error.

Yeah, also on my machine there aren't any email icons available in hicolor either, I might check out why. Actually implementing the icon_lookup spec sounds kind of fun to me. I suggest I give implementing that a shot and maybe still add an option to the config where you can override it, as I do know how much of a pain icon themes can be on linux.

I'll take a look at it tonight/tomorrow.

[jonhoo]

Actually implementing the icon_lookup spec sounds kind of fun to me. I suggest I give implementing that a shot and maybe still add an option to the config where you can override it, as I do know how much of a pain icon themes can be on linux.

Oooh, that'd be awesome! I'd suggest you implement it as its own crate, as I'm sure there are others who may find that useful too :)

[DanielVoogsgerd]

Will do. I'll link it here when it is ready. Or at least, when I'm semi-confident it doesn't catch fire.

[DanielVoogsgerd]

Okay still catching fire, not tested whatsoever. Just a version that builds. DanielVoogsgerd/icon-finder-rs

EDIT: Well that sounds pessimistic, most of the code is there. I just have to make sure/validate that it works and the API needs to be a little more smooth I think.