Closed Bug 1532378 Opened 5 years ago Closed 4 years ago

HiDPI - Blurry icons in sidebar

Categories

(Thunderbird :: Theme, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 77.0

People

(Reporter: aleca, Assigned: aleca)

References

Details

Attachments

(4 files, 24 obsolete files)

64.09 KB, image/png
Details
35.50 KB, image/png
Details
10.95 KB, image/png
Details
61.92 KB, patch
mkmelin
: review+
Paenglab
: ui-review+
Details | Diff | Splinter Review
Attached image blurry-icons.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Open Thunderbird 60 on a HiDPI display on Linux.
Distribution: elementary OS 5, based on Ubuntu 18.04
Current screen resolution: 3840 x 2160
No scaling applied to the screen.
Current text size set to "2x"

Actual results:

The OS icons used in the sidebar are blurred compared to the Thunderbird icons used in the top toolbar.

Expected results:

2 Possible solutions:

  • Detect the screen resolution and Fetch the properly scaled icons to compensate for HiDPI display.
  • Ship custom icons to avoid using the OS icons.

This is because we have no HiDPI icons and the normal icons are upscaled. The same applies to Windows. Only macOS has HiDPI icons.

If you guys want I could take care of creating HiDPI variations for all the icons.
What would be the priority for this?

I'd say, the icons in the main view have the highest priority. We could also think of using SVG icons like we do for the toolbars and some other places.

I agree, SVG should be the way to go for every icon.
I can slowly take care of this, starting from the most obvious icons in the sidebar.
Is there any style guide or design system I should follow to update the icons?
Would a style refresh be also considered?

You can propose a style refresh. :-) Maybe also a unified one that fits on all platform. That would make many things easier.

That would be great, and I would love to do that.
I'll start drafting a visual overview of the current icon style and some possible approaches for an updated and unified style.

Just for documentation purposes, we have a style guide based on Firefox's here: https://github.com/uracreative/thunderbird

Needs to be moved to our own repo and pushed up somewhere like style.thunderbird.net

Hmm, those are the old ugly Linux icons, it looks much different on Windows. BTW, how old is your build with the stars cut off on the right. That's been fixed, bug 1521376, even on ESR.

I'm running 67.0a1, and I just did a pull this morning.

Grrrr, and the stars are still cut off. What's happening, Richard? Was the fix for bug 1521376 only effective on Windows?

Flags: needinfo?(richard.marti)

This could be a scaling issue under HiDPI.

Flags: needinfo?(richard.marti)

I can confirm that on my 1080p Linux laptop, the stars are not cut off.

Should I open a separate bug report for the Star issue in HiDPI or add a comment to bug 1521376?

New bug please. Various issues in the same bug, where some parts have already been landed and even backported is a management nightmare.

Alessandro, do you have a bug to point this at as a duplicate? Do you believe this is resolved?

Flags: needinfo?(alessandro)

This is not solved, but there's some work going on bug 1559867, which will introduce SVG Photon icons for account settings.
After that we should follow up on this and implement them on the sidebar as well to keep the look consistent and solve the HiDPI problem.

Flags: needinfo?(alessandro)
Attached image Screenshot from 2019-10-22 10-04-24.png (obsolete) —

Half the required icons are already part of the shared Photon icon themes at /source/comm/mail/themes/shared/mail/icons/ as shown in that screenshot. I don't know mercurial to also provide the patch, but mostly anyways is just the same adjustments in /source/comm/mail/themes/linux/mail/folderPane.css

/* ..... Trash ..... */

.tabmail-tab[type="folder"][SpecialFolder="Trash"],
treechildren::-moz-tree-image(folderNameCol, specialFolder-Trash) {
  list-style-image: url("chrome://messenger/skin/icons/delete.svg");
  /* list-style-image: url("chrome://messenger/skin/icons/folder-pane.png"); */
  /* -moz-image-region: rect(176px 16px 192px 0px) !important; */
}

Newer before looked at Thunderbird code, so this info is likely trivial to you :-)

Isn't that what Richard said in comment #1:

This is because we have no HiDPI icons and the normal icons are upscaled.

Those PNGs are scaled up and don't look good, but if you use SVGs instead, they look good.

Richard, can we fix that?

Flags: needinfo?(richard.marti)

Like Alessandro wrote in comment 16, when bug 1559867 is done we should have the needed SVG icons to finish this bug. Only applying the half of the icons would look much worse than now.

Flags: needinfo?(richard.marti)
Assignee: nobody → alessandro
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attached image Screenshot from 2020-04-02 17-36-20.png (obsolete) —

Some work in progress on this.
I created some custom icons for some variations we need to cover.

Attachment #9137911 - Flags: feedback?(richard.marti)
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

First WIP patch to see how this will look.
I tackled only Linux and temporarily ignored macos and windows to focus on one platform.

A couple of considerations.

  • Using monochromatic SVG removes that visual separation we were naturally getting from colored images, but it enables us to control the color of those icons when we receive a new message or the server goes offline.
  • I gave a min-height of 1.6rem to the treeitems in order to add a little bit more breathing room to the list and let the height of those items adapt when the font scales up or down to better follow HiDPI scaling and accessibility for visually impaired users.
  • The overall UI feels a little bit dull and we should implement some brand colors in a smart and useful way. Or maybe allowing the users to color their folders like we do for tags?

Thoughts?

Attachment #9137921 - Flags: feedback?(richard.marti)
Attachment #9137921 - Flags: feedback?(mkmelin+mozilla)
Comment on attachment 9137921 [details] [diff] [review]
1532378-folderpane-icons.diff

Review of attachment 9137921 [details] [diff] [review]:
-----------------------------------------------------------------

It's indeed quite dull, and I don't think I like the extra spacing too much lost space. 
I guess the general idea could be useful though. Letting users color their folders is apparently a much asked for feature...  go figure.

The icons seem a bit smaller than before, especially for the search folders the details are now small enough that they don't really show. 

Since linux is using stock icons for many of the folders that integrates well with the system. Not sure how we'd get that same integration if we use this system. On other platforms that's not an issue of course.
Attachment #9137921 - Flags: feedback?(mkmelin+mozilla)
Comment on attachment 9137911 [details]
Screenshot from 2020-04-02 17-36-20.png

👍 Looks good.
Only the "Local Folder" icon looks a bit alien with its filled appearance. Maybe you could use a half transparent filling like FX uses in the bookmarks for the folders. And the "Sent" icon looks visually smaller than the other icons because of its shape.

Maybe we should stay at 16px icons as, like Magnus wrote, we can loose details. 16px are already small for fine details. With HiDPI this can be less of a problem as it could be virtually 28px.
Attachment #9137911 - Flags: feedback?(richard.marti) → feedback+
Attached image folderPane-Windows.png (obsolete) —

I've tested your patch on Windows. With 14px icon size on the left you see that some icons are blurry and with 16px sharp. This could also be a issue of the not correct scaling in treeitems (like the twisty not scaling issue).

Comment on attachment 9137921 [details] [diff] [review]
1532378-folderpane-icons.diff

Looks good with the size issue fixed as I wrote earlier. You can unify more rules than the ones you did like the waiting.svg and the warning.svg rules.

And yes, we could do more with the colours like when new/unread message are in the folder etc.
Attachment #9137921 - Flags: feedback?(richard.marti) → feedback+
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

For testing on Windows did the same as you did for Linux. Plus I removed a min-height rules which is no more used because of your min-height: 1.6rem;.
About this min-height, I think we should leave it. First it was a outcry on Windows but now the users are accustomed to it. And for the ones that absolutely don't want it, can set a userChrome.css rule.

(In reply to Magnus Melin [:mkmelin] from comment #22)

Since linux is using stock icons for many of the folders that integrates
well with the system. Not sure how we'd get that same integration if we use
this system. On other platforms that's not an issue of course.

It integrates well with the system but no more with TB like the Photon icon or other areas. We should make that TB looks consistent in itself.

Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

Same patch as before but with 16px icon size.

Attachment #9137921 - Attachment is obsolete: true
Attachment #9138053 - Attachment is obsolete: true
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

Now also with the Mac folderPane.css converted. Mac needed a min-height: 1.7rem;. Width 1.6rem the icons where cut off at the bottom. If you want it taller you can set it in the Mac file, but it seems it needs the some aligning of the text/icon. Then I could follow on Windows because now is no difference to the actual height.

Attachment #9138099 - Attachment is obsolete: true
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

Patch updated after landing of bug 1589005. And also made the icon highlight when new messages arrived.

Attachment #9138135 - Attachment is obsolete: true

Awesome, thank you so much.
I'll take care of updating the folder and sent icon.

How do we want to handle the colouring of folders?
Should we follow the same approach of tags, or is there a better method we could implement?

I'd assume we just put a color picker in the folder properties.

Yes, a colour picker in the properties would be awesome.

Attached image Screenshot from 2020-04-07 10-25-43.png (obsolete) —

I noticed you added a #ffba1e colour for the icon fill when a new message is received.
Doesn't it look weird?
I guess the objective was to emulate the "yellow star" we use in 68, right?
If that distinction is necessary I guess we should implement an SVG indicator.

I was expecting for the icon to inherit the same primary colour of the text and keeping the entire item consistent.
This also opens up the question on how to handle the custom colouring of those items.
Should we allow users to colour only the icon, only the text, the entire item, or manage the icon and text colour independently?

Attachment #9138900 - Flags: feedback?(richard.marti)
Comment on attachment 9138900 [details]
Screenshot from 2020-04-07 10-25-43.png

This was only as a proposal to see how it looks. This was also why I noted especially. It's not really needed as the blue text already shows the new arrived messages. I'm okay to remove this change.

I think, we should only let the user paint the icon to let him distinguish the folders. When the whole line gets the custom colour, the folder pane could be too colourful. Depending of the implementation we could also go into problems to override the custom colours with our CSS code.
Attachment #9138900 - Flags: feedback?(richard.marti)
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

Indeed, I agree with everything you said.

This is an updated patch with the new Sent and Folder-Local icons.
I'm gonna implement a super easy colour picker as a first implementation.
Later on we can consider if a more advanced colour manager might be needed, like what we have for tags.

Attachment #9138920 - Flags: feedback?(richard.marti)
Attachment #9138920 - Flags: feedback?(mkmelin+mozilla)
Comment on attachment 9138920 [details] [diff] [review]
1532378-folderpane-icons.diff

Looks better. :-)

The local folder doesn't work on well on dark theme because the fill rectangle is always black because the fill="" is missing. I'll attach one that works. I also tweaked the opacity to be better visible.
Attachment #9138920 - Flags: feedback?(richard.marti) → feedback+
Attached image folder-local.svg (obsolete) —

Local folder icon that works better.

Attached image outbox.png (obsolete) —

The outbox icon is a bit blurry because the lines don't match the pixel grid (https://github.com/nt1m/thunderbird-icons/ read the README.md). It could look good on HiDPI screens but not on LoDPI as you can see on the magnified screenshot.

Also the sent icon has some blurriness.

Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

I updated the patch with thew new folder-local.svg, and improved the other icons.
The sent icon is not super easy to align to the grid due to its nature, but with the tweaks I did on HiDPI looks sharp. Let me know how it looks on a LoDPI monitor.

Now, it comes the interesting part, adding colours to the icons.

I created a first barebone context menuitem which creates an <input type="color"> and triggers it, as it seems is not possible to trigger the HTML color picker independently.
These are my questions:

  1. The document.popupNode returns the entire tree, not the treechildren where the right click actually originated. Is there a way to access that node?
  2. How do we want to store this value? Should we create something similar to the C++ nsMsgDBFolder::SetFlag() method?
  3. Do you have a better approach on how to handle all of this?
Attachment #9138346 - Attachment is obsolete: true
Attachment #9138920 - Attachment is obsolete: true
Attachment #9138938 - Attachment is obsolete: true
Attachment #9138940 - Attachment is obsolete: true
Attachment #9138920 - Flags: feedback?(mkmelin+mozilla)
Attachment #9139000 - Flags: feedback?(richard.marti)
Attachment #9139000 - Flags: feedback?(mkmelin+mozilla)
Comment on attachment 9139000 [details] [diff] [review]
1532378-folderpane-icons.diff

Looks good now.

I optimized the icons with https://jakearchibald.github.io/svgomg/ to make them smaller.
The newsgroup.svg had some blurriness at the end of the text lines and the padlock of globe-secure.svg too. Fixed them. I'll attach your patch with the updated icons.
Attachment #9139000 - Flags: feedback?(richard.marti) → feedback+
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

Same patch with the optimized icons.

(In reply to Alessandro Castellani (:aleca) from comment #40)

These are my questions:

  1. The document.popupNode returns the entire tree, not the treechildren where the right click actually originated. Is there a way to access that node?

See https://searchfox.org/comm-central/rev/a135545ee1a017e948df44919e045b1fb3322606/mail/base/content/msgMail3PaneWindow.js#1354

  1. How do we want to store this value? Should we create something similar to the C++ nsMsgDBFolder::SetFlag() method?

Likely nsIDBFolderInfo.setCharProperty.
It's possible it has to be something accessible by nsIMsgFolderCacheElement to work in the tree.

Comment on attachment 9139000 [details] [diff] [review]
1532378-folderpane-icons.diff

Review of attachment 9139000 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/base/content/mainPopupSet.inc.xhtml
@@ +511,5 @@
>                oncommand="MsgMarkAllFoldersRead();"/>
>      <menuseparator id="folderPaneContext-sep4"/>
> +    <menuitem id="folderPaneContext-changeIconColor"
> +              label="&folderContextChangeIconColor.label;"
> +              oncommand="folderChangeIconColor(document.popupNode);"/>

I don't think it needs to be in the context menu. Would probably put a color box just next to the name, once you open the folder properties dialog.
Attachment #9139000 - Flags: feedback?(mkmelin+mozilla)
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

I updated your patch after the landing of bug 1631394 and the steal of your globe-secure.svg icon in bug 1631779.

To apply you need bug 1631779 first.

Attachment #9139000 - Attachment is obsolete: true
Attachment #9139135 - Attachment is obsolete: true
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

I updated the icons and implemented the color picker in the Folder Properties (I will add that in the settings of server folders later).
I'm saving the enable/disabled state to allow the user to "reset" the color to the default, and I'm saving the color string as well.

I need some help and direction on how to tackle the next part, which is adding an inline style to the treechildren with custom fill color.

I created the setFolderColor method in the FolderPane in order to pass the color and get the tree index of the folder I'm editing, but I'm not able to figure out how to get the actual DOM element instead of the JS Object.

I'm asking a little feedback to confirm the correct approach and have a bit of direction on how to solve this issue.

Attachment #9142047 - Attachment is obsolete: true
Attachment #9142824 - Flags: feedback?(richard.marti)
Attachment #9142824 - Flags: feedback?(mkmelin+mozilla)
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

I forgot to add the shared FolderPane.css to the jar file.

Attachment #9142824 - Attachment is obsolete: true
Attachment #9142824 - Flags: feedback?(richard.marti)
Attachment #9142824 - Flags: feedback?(mkmelin+mozilla)
Attachment #9142834 - Flags: feedback?(richard.marti)
Attachment #9142834 - Flags: feedback?(mkmelin+mozilla)
Comment on attachment 9142834 [details] [diff] [review]
1532378-folderpane-icons.diff

Looks good. I'm only not so happy with the position of the colour picker in the folder properties dialog. I think, it shouldn't be on the first position where the folder label should be.
Attachment #9142834 - Flags: feedback?(richard.marti) → feedback+

We can also potentially keep this patch focused only on replacing the icons, and then opening a follow up bug to implement the custom colours.
This would make it easier to review and avoid further bitrotting.

Comment on attachment 9142834 [details] [diff] [review]
1532378-folderpane-icons.diff

Review of attachment 9142834 [details] [diff] [review]:
-----------------------------------------------------------------

Agreed with Richard, maybe we can just have a
Name: [ Fooo bar               ]  [ rgb ]

But the question is then how to reset. And what to do for light/dark theme.

Unfortunately, styling treechildren - I don't know to what degree it's possible.
Attachment #9142834 - Flags: feedback?(mkmelin+mozilla)

Should we limit this bug to simply swapping the icons, and then creating a follow up for the custom colours?

Flags: needinfo?(mkmelin+mozilla)

Unclear. On linux at least, with the current patch folders look quite dull with no colors. It doesn't necessarily have to be customizable colors - but I don't know what plans you have? OTOH, the out of the box experience shouldn't require adding colors.

Flags: needinfo?(mkmelin+mozilla)
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

Updated the patch after I used the junk icon from this bug in bug 1632878 and I found also other missing icons in jar.inc.mn.

I think we should separate the icons change and the icon colourisation. In the mean tims we could hard code some icons with a colour to show how it looks and give more colour to the tree. We're not on release and we can try things here to get some feedback from the users.

Attachment #9142834 - Attachment is obsolete: true
Attachment #9143602 - Flags: feedback+

I was thinking the same, some default colours for the tree will help us remove the dullness and ship something beautiful out of the box with vector icons.
Colour customization can come in a follow up patch.

Attachment #9138900 - Attachment is obsolete: true
Attachment #9103182 - Attachment is obsolete: true
Attachment #9137911 - Attachment is obsolete: true
Attachment #9048262 - Attachment filename: Screenshot from 2019-03-04 11-14-32.png → blurry-icons.png
Attachment #9048262 - Attachment description: Screenshot from 2019-03-04 11-14-32.png → blurry-icons.png
Attached image folder-properties.png (obsolete) —

Here's a test on how we can handle the color button tin the folder property dialog.
Inline, we can have a reset button that sets the color back to the default value. That button has a tooltip that reads "Reset default color".
We can later style this dialog better with the themeable styling that Richard is implementing.

Attachment #9144090 - Flags: feedback?(richard.marti)
Attachment #9144090 - Flags: feedback?(mkmelin+mozilla)
Attached image folder-icons.png (obsolete) —

Please, partially ignore the colours because they're not 100% accurate as I've been applying them as overlay in my design app to quickly prototype it visually without updating the CSS.

The idea here is to distinguish the type of folders with our brand colours.

  • IMAP, POP, and remote folders in general should come with the primary colour (our primary blue or do we let inherit it form the OS?)
  • Local folder can have a slightly darker Ink colour
  • Feed will have their typical orange
  • Newsgroups will have a purple colour

We can decide if these colour should apply only to the parent folders or also to all the children elements.

I think this approach is the right one as we remove the dullness of grey icons, we ship our brand colour better controlling the UI, and we improve the visual distinctions between account types.

Attachment #9144096 - Flags: feedback?(richard.marti)
Attachment #9144096 - Flags: feedback?(mkmelin+mozilla)
Comment on attachment 9144090 [details]
folder-properties.png

Looks good. Maybe better tooltip: "Reset to default color".
Attachment #9144090 - Flags: feedback?(richard.marti) → feedback+
Comment on attachment 9144096 [details]
folder-icons.png

Yes, we could go this way. Or what about colour depending the type, like green for the inboxes, blue the sent boxes, red the trash? Don't take the colours, they are only for the imagination what I mean.
Attachment #9144096 - Flags: feedback?(richard.marti) → feedback+
Attached image folder-icons-rainbow.png (obsolete) —

That might work, but I'm worried it might turn into a little bit of a messy rainbow.

Comment on attachment 9144113 [details]
folder-icons-rainbow.png

I'm using unified folders which then looks more consistent. ;-)

A note about Local Folders: this can also be just a pop account... We don't really promote that setup option these days, but it's possible.

Attachment #9144090 - Flags: feedback?(mkmelin+mozilla) → feedback+
Comment on attachment 9144096 [details]
folder-icons.png

Not sure if local folders should be special.
I think the later screenshot with some colors could be nicer. This screenshot doesn't have any normal folders, so it's a bit hard to say.
Attachment #9144096 - Flags: feedback?(mkmelin+mozilla)

(In reply to Richard Marti (:Paenglab) from comment #58)

Comment on attachment 9144096 [details]
folder-icons.png

Yes, we could go this way. Or what about colour depending the type, like
green for the inboxes, blue the sent boxes, red the trash? Don't take the
colours, they are only for the imagination what I mean.

If this is implemented, please create a pref to have the possibility to disable this kind of color coding. For my feeling this is adding to much "noise" to he display.

Attached image folder-icons.png (obsolete) —

I did some experiment with our brand colours in trying to find a balance and the perfect default to ship this patch.

INK
I started by giving all the icons a default INK colour in order to create a better visual separation with the text.
I personally don't mind this default status as it's clean and open to customization.
This is also the best scenario when dealing with new messages, connection errors, warnings, marked for deletion, and offline statuses, which all update the colour of the icon and it makes those warning clear and easy to spot.

RAINBOW
I did some test also with colouring all the icons (RAINBOW) and testing how they look with a regular or unified sorting.
This is my least favourite as it makes the whole section very noisy and distracting.
We also lose the visual separation and focal point given when receiving a new message, alongside making it very difficult to spot status warnings based on colours.

TOP LEVEL
As a last test, I coloured only the top level folders, in order to increase visual separation between the top tree elements, and add a little bit of colouring to remove the default dullness without affecting the various status changes and warnings.

Attachment #9138040 - Attachment is obsolete: true
Attachment #9144096 - Attachment is obsolete: true
Attachment #9144113 - Attachment is obsolete: true
Attachment #9144480 - Flags: feedback?(richard.marti)
Attachment #9144480 - Flags: feedback?(mkmelin+mozilla)

After further thinking about it, we should got with a TOP LEVEL solution, as it creates better visual hierarchy without overwhelming the user or the whole section.

If we use the RAINBOW, than we'll need to find a new paradigm to reflect all the different states, which is something we should avoid as it partially defeats the purpose of adopting SVGs.

I would also update the TOP LEVEL to only use our brand blue colour by default, as using different colours for the other sections, like Feed and Newsgroups, doesn't really translate well and creates a conflict between aesthetic choices (RSS Brand colour) and status colours (orange spam).

Attached image icons-top-level.png

For reference.

Comment on attachment 9144480 [details]
folder-icons.png

I think we should start with the TOP LEVEL approach.
Attachment #9144480 - Flags: feedback?(richard.marti) → feedback+
Comment on attachment 9144480 [details]
folder-icons.png

Agreed top level would be nicest of these.
Attachment #9144480 - Flags: feedback?(mkmelin+mozilla) → feedback+
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

Patch updated with the TOP LEVEL colour approach.
I also removed the custom colour part as I will implement that in a follow up patch.

Richard, can you see if everything looks readable on the dark variation, especially on Windows?

Attachment #9143602 - Attachment is obsolete: true
Attachment #9144090 - Attachment is obsolete: true
Attachment #9144480 - Attachment is obsolete: true
Attachment #9144763 - Flags: ui-review?(richard.marti)
Attachment #9144763 - Flags: review?(mkmelin+mozilla)
Attached patch 1532378-folderpane-icons.diff (obsolete) — Splinter Review

Unbitrotted.

Attachment #9144763 - Attachment is obsolete: true
Attachment #9144763 - Flags: ui-review?(richard.marti)
Attachment #9144763 - Flags: review?(mkmelin+mozilla)
Attachment #9144768 - Flags: ui-review?(richard.marti)
Attachment #9144768 - Flags: review?(mkmelin+mozilla)

How it looks with the dark theme with a new message in a folder. I think we can go with this.

Comment on attachment 9144768 [details] [diff] [review]
1532378-folderpane-icons.diff

Review of attachment 9144768 [details] [diff] [review]:
-----------------------------------------------------------------

message-secure.svg, newsgroup.svg and outbox.svg aren't packaged and you can remove library.svg because it's not used.

::: mail/themes/shared/mail/folderPane.css
@@ +6,5 @@
> +  --default: #363959;
> +  --primary: #0060df;
> +}
> +
> +@media (prefers-color-scheme: dark) {

This rule isn't needed. The :root[lwt-tree-brighttext] {} rule applies with the system dark theme too.
Attachment #9144768 - Flags: ui-review?(richard.marti)

Thanks for the review and the dark variation screenshot.
Patch updated.

Attachment #9144768 - Attachment is obsolete: true
Attachment #9144768 - Flags: review?(mkmelin+mozilla)
Attachment #9144802 - Flags: ui-review?(richard.marti)
Attachment #9144802 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9144802 [details] [diff] [review]
1532378-folderpane-icons.diff

Many thanks.
Attachment #9144802 - Flags: ui-review?(richard.marti) → ui-review+
Attachment #9144802 - Flags: review?(mkmelin+mozilla) → review+
Target Milestone: --- → Thunderbird 77.0

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/87bdc889cbad
Implement photon icons to the Folder Pane. r=mkmelin, ui-r=paenglab

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Regressions: 1636775
Regressions: 1637600

Because you can only set an outline colour, many colours are now not very visible or do not work as well in dark as in light mode or vis versa.
So if you need to change theme then you may find half the folder icon colours no longer seem practical.

There is no means of colouring the space inside the icon - if just the outline then yellows just disappear.
How do I colour the entire icon and not just an outline ?

There is also no means of setting all the eg: 'sent' folders with a colour in one go. Some people have hundreds of folders so the problem is rather obvious.

Is there a means of replacing all the version 78 icons shown in Folder Pane with all icons that were used in 68, ?
I presume there is a folder that held all the icons, so could one be swapped for another.

Because you can only set an outline colour, many colours are now not very visible or do not work as well in dark as in light mode or vis versa.
So if you need to change theme then you may find half the folder icon colours no longer seem practical.

The custom colouring of icons is an "extra" feature to allow users to highlight the folders they're more interested in.
The default colouring for both light and dark theme takes care of guaranteeing AAA accessibility contrast.
If the user wants to customize every single folder, then switch theme, and customize them again, it's a user's choice.

How do I colour the entire icon and not just an outline ?

It's not possible. The Photon icons come only with the thick outline.
If a colour doesn't work, you have the freedom to choose one with a better contrast.

There is also no means of setting all the eg: 'sent' folders with a colour in one go. Some people have hundreds of folders so the problem is rather obvious.

We don't currently support these specific customization as they can be many and mostly edge cases, which is too cumbersome to maintain.

Is there a means of replacing all the version 78 icons shown in Folder Pane with all icons that were used in 68, ?
I presume there is a folder that held all the icons, so could one be swapped for another.

That's not how it works as the previous icons were PNGs, not scalable, and the CSS of the tree changed to accommodate new icons.
You could create an add-on to implement your own icons if you wish.
This is the file handling those icons based on specific folder properties: https://searchfox.org/comm-central/rev/dda94e693bf61db1374610fa75fc4dddc223eaeb/mail/themes/shared/mail/folderPane.css

Thanks Alessandro for info as I'm sure someone will ask in the support forum.

You need to log in before you can comment on or make changes to this bug.