Skip to content
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

Differentiate icons for improved skinning #1574

Open
hacst opened this issue Feb 19, 2015 · 1 comment
Open

Differentiate icons for improved skinning #1574

hacst opened this issue Feb 19, 2015 · 1 comment
Labels
feature-request This issue or PR deals with a new feature theme ui

Comments

@hacst
Copy link
Contributor

hacst commented Feb 19, 2015

http://forums.mumble.info/viewtopic.php?f=8&t=1245 describes issues with selectively skinning toolbar icons. We reuse the same icon in a lot of places that might require individual adjustment for where they will appear.

@xpoke is probably the one in the best position to suggest where we have issues with that and how to solve them. Especially when it comes to what's possible from QSS and what we have to do by offering separately named icon files that can be exchanged. Also this issue might exist for more icons than mentioned in the post.

@hacst hacst added the ui label Feb 19, 2015
@xpoke
Copy link

xpoke commented Feb 20, 2015

This issue is compiled of both the issue of allowing different assets for different areas while also not breaking existing themes. We already separated a few icons in the snapshot in this commit, but if we're gonna change more icons it might be better to not completely break all existing themes.

A relatively simple way would be to check for the existence of specific icon, and if not found, fallback to the "generic" icon.
For example from the above commit, one could check for priority_speaker.svg, and if not found, use audio-input-microphone.svg
This would make the existing way of loading icons slightly more complicated, but since we're going for complete asset separation, it would only need be done once. It might be a good time to consider implementing dynamic loading of icons (instead of only at program start).

A better way to differentiate these without using long names like deafened_self_toolbutton.svg would be to make directories depending on use, for example user/deafened_self, toolbar/deafened_self.svg and tray/deafened_self.svg, etc.
It stands to reason that simply the existence of a "tray" directory means that the theme creator wanted to implement separate icons for the tray area, and allows simple fallback logic if such a directory doesn't exist.

In this list, "toolbutton" means a button on the toolbar, "indicator" means an icon to the right side of a user/channel, "avatar" means icon to the left of a user/channel, and "tray" means the icon shown in the taskbar tray area. Doing this by memory, hopefully I'm not missing anything.

deafened_self.svg - self deafened toolbutton / indicator / tray / generic "deafened" indicator in overlay
deafened_server.svg - server deafened indicator / tray
muted_self.svg - self muted indicator / tray / generic "muted" indicator in overlay
muted_server.svg - server muted indicator / tray
muted_suppressed.svg - channel muted indicator / tray
talking_off.svg - idle state avatar / tray
talking_on.svg - talking state avatar / tray
talking_whisper - whisper state avatar / tray
talking_alt.svg - shout state avatar / tray
actions/media_record.svg - record toolbutton / recording indicator
categories/applications-internet.svg - server browser toolbutton / "public internet" icon in server browser
emblems/emblem-favorite.svg - friend indicator / "favorites" icon in server browser
mumble.svg - program window icon / "about" dialog logo / default state tray (when "talking status in tray" option disabled)

actions/audio-input-microphone.svg * - unmuted state toolbutton / priority speaker indicator
comment.svg * - self comment toolbutton / user and channel unread comment indicator

  • until this commit (I am not including filter.svg as it was never in a stable version)

@Hartmnt Hartmnt added feature-request This issue or PR deals with a new feature theme labels Jun 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request This issue or PR deals with a new feature theme ui
Projects
None yet
Development

No branches or pull requests

3 participants