[APP][5.0+] FairEmail - Fully featured, open source, privacy oriented email app

[M66B]

To HTML gurus: this is my attempt of a custom implementation of "algorithmic darkening" (display messages on a dark background, even though they weren't designed for this) for the original message view on Android before version 10:

https://github.com/M66B/FairEmail/blob/master/patches/invert.html

Result:

https://rawcdn.githack.com/M66B/Fai...097ed999a3e77c56c1b97388c/patches/invert.html

Can this be improved? Are there side effects?

 

[mkasimd]

To HTML gurus: this is my attempt of a custom implementation of "algorithmic darkening" (display messages on a dark background, even though they weren't designed for this) for the original message view on Android before version 10:

https://github.com/M66B/FairEmail/blob/master/patches/invert.html

Result:

https://rawcdn.githack.com/M66B/Fai...097ed999a3e77c56c1b97388c/patches/invert.html

Can this be improved? Are there side effects?

Is it possible to check the original HTML's background brightness before doing this? Because it'd be stupid if an email was already sent with a dark background and a light text, and then inverting the text to dark with a black background

 

[M66B]

Is it possible to check the original HTML's background brightness before doing this? Because it'd be stupid if an email was already sent with a dark background and a light text, and then inverting the text to dark with a black background

That's indeed a potential problem, but I don't know how (yet?).

 

[M66B]

@mkasimd there are no changes needed for "set" background colors, please see the updated example:

https://rawcdn.githack.com/M66B/Fai...aedcdc1448bff3da9879be8cd/patches/invert.html

 

[mkasimd]

That's indeed a potential problem, but I don't know how (yet?).

Apparently there's a while field of science behind the question of what colors are perceived as light / bright. This article is interesting on the topic:

Web Accessibility: Understanding Colors and Luminance - Accessibility | MDN

When designing visual and readable content with the aim of accessibility for all sighted users, it is important to have an understanding of light, color, and perception. This page specifically discusses:

developer.mozilla.org

@mkasimd there are no changes needed for "set" background colors, please see the updated example:

https://rawcdn.githack.com/M66B/Fai...aedcdc1448bff3da9879be8cd/patches/invert.html

But this should work too, I think. In the worst case, we can send a few emails with different background colors in a test version before you push an official release. Just to be certain.

 

[M66B]

Apparently there's a while field of science behind the question of what colors are perceived as light / bright. This article is interesting on the topic:

Web Accessibility: Understanding Colors and Luminance - Accessibility | MDN

When designing visual and readable content with the aim of accessibility for all sighted users, it is important to have an understanding of light, color, and perception. This page specifically discusses:

developer.mozilla.org

But this should work too, I think. In the worst case, we can send a few emails with different background colors in a test version before you push an official release. Just to be certain.

FairEmail already adjusts colors for the reformatted message view, using magic science ;-)

For now I am going to wait what Google says about forcing dark mode. It would be better if the browser did this instead of manipulating the HTML. Maybe I I'll leave it like it is, which means that there will be a message that Google removed dark mode for Android before version 10. Let's say that reviews are not very motivating to workaround Google's decision this problem.

 

[M66B]

Version 1.1930 is available on GitHub now.

Changelog/download:
https://github.com/M66B/FairEmail/releases

If you enable debug mode (last option of the miscellaneous settings tab page), it is possible to enable the option "Fake dark", in the debug panel, which uses a custom algorithmic dark mode (on all Android versions for now). I would like you to test if this works okay for all messages.

@zinjashike sort on sender will show email addresses and names (if available) with the version.

 

[nadir husain]

So far works fine

 

[O_DoC]

(...) I would like you to test if this works okay for all messages.

Android 10.
So far so good

 

[mkasimd]

Version 1.1930 is available on GitHub now.

Changelog/download:
https://github.com/M66B/FairEmail/releases

If you enable debug mode (last option of the miscellaneous settings tab page), it is possible to enable the option "Fake dark", in the debug panel, which uses a custom algorithmic dark mode (on all Android versions for now). I would like you to test if this works okay for all messages.

@zinjashike sort on sender will show email addresses and names (if available) with the version.

Android 12 here. I found some issues with the original message view when the original message has a black background.

The original message view adds white background to the text fields. It looks unnatural. I have attached some screenshots and can also send you the .eml if that helps you.

Edit: seems to invert all colors.

 

[bmwdroid]

Version 1.1930 is available on GitHub now.

Changelog/download:
https://github.com/M66B/FairEmail/releases

If you enable debug mode (last option of the miscellaneous settings tab page), it is possible to enable the option "Fake dark",.......

Should I see a difference when being on dark theme already?
Lineage 19.1=A12
Tried it but didn't notice any changes (except of loads of unwanted notices).

 

[mkasimd]

Should I see a difference when being on dark theme already?
Lineage 19.1=A12
Tried it but didn't notice any changes (except of loads of unwanted notices).

If you enable the debug mode and within the debug options the "fake dark" option, you can view the original message in a dark theme. Meaning, you'll have to open the original message view using "[ ]" on a message selected. Also, you might need to enable a dark theme in the Display settings to test this.

____
@M66B, suggestion to improve fake dark:

1. First check, if a background color is specified
2. If yes, then convert it into RGB (if not, apply the current "fake dark" and show the message -> the end)
3. Apply the HSP color model to determine the RGB color's perceived brightness (link below)
4. If the perceived brightness is below a specific threshold (e.g. 20), then do not change anything and show the original message as is. If the perceived brightness is higher, then apply the already available "fake dark" implementation

This should improve things even if Google re-introducing the method in the Androidx library is definitely the much better option.

Now link to the HSP color model (color palette with the calculated brightness results in the attachment, taken from nbdtech.com)

HSP Color Model - Alternative to HSV (HSB) and HSL

Basically:

brightness  =  squareRootOf( .299 * R^2 + .587 * G^2 + .114 * B^2 )

Addendum: a threshold of 20 is an okayish estimate because the material.io dark theme color results in ≈ 18,27 HSP. But then #191919 results in ≈ 25,37 HSP, and #191a19 in ≈ 25,96 HSP. Meaning something between 25 and 30 might be a better estimate. Or an HSL lightness of 0 - 10 %. Both methods can be valid.

 

[M66B]

If you enable the debug mode and within the debug options the "fake dark" option, you can view the original message in a dark theme. Meaning, you'll have to open the original message view using "[ ]" on a message selected. Also, you might need to enable a dark theme in the Display settings to test this.

____
@M66B, suggestion to improve fake dark:

1. First check, if a background color is specified
2. If yes, then convert it into RGB (if not, apply the current "fake dark" and show the message -> the end)
3. Apply the HSP color model to determine the RGB color's perceived brightness (link below)
4. If the perceived brightness is below a specific threshold (e.g. 20), then do not change anything and show the original message as is. If the perceived brightness is higher, then apply the already available "fake dark" implementation

This should improve things even if Google re-introducing the method in the Androidx library is definitely the much better option.

Now link to the HSP color model (color palette with the calculated brightness results in the attachment, taken from nbdtech.com)

HSP Color Model - Alternative to HSV (HSB) and HSL

Basically:

brightness  =  squareRootOf( .299 * R^2 + .587 * G^2 + .114 * B^2 )

Addendum: a threshold of 20 is an okayish estimate because the material.io dark theme color results in ≈ 18,27 HSP. But then #191919 results in ≈ 25,37 HSP, and #191a19 in ≈ 25,96 HSP. Meaning something between 25 and 30 might be a better estimate. Or an HSL lightness of 0 - 10 %. Both methods can be valid.

The challenge is to put this in CSS because modifying a message is not an option because there will be many edge cases because CSS/HTML is pretty complex. The reformatted messages view as it is now was months of work and it is still not perfect and will never be because that would mean developing a browser.

At this moment I will keep everything as simple as possible having heard today that the average life expectancy of my mother is one month. Intensive chemo therapies might help (30% chance) and radio therapy is being investigated out of normal treatment strategies. I am feel pretty down right now.

 

[nadir husain]

The challenge is to put this in CSS because modifying a message is not an option because there will be many edge cases because CSS/HTML is pretty complex. The reformatted messages view as it is now was months of work and it is still not perfect and will never be because that would mean developing a browser.

At this moment I will keep everything as simple as possible having heard today that the average life expectancy of my mother is one month. Intensive chemo therapies might help (30% chance) and radio therapy is being investigated out of normal treatment strategies. I am feel pretty down right now.

Strength and prayers. We will all also pray. Best wishes

 

[mkasimd]

The challenge is to put this in CSS because modifying a message is not an option because there will be many edge cases because CSS/HTML is pretty complex. The reformatted messages view as it is now was months of work and it is still not perfect and will never be because that would mean developing a browser.

At this moment I will keep everything as simple as possible having heard today that the average life expectancy of my mother is one month. Intensive chemo therapies might help (30% chance) and radio therapy is being investigated out of normal treatment strategies. I am feel pretty down right now.

Of course, you should be with your mother. Me suggesting something doesn't mean I expect you to commit something the next hour. Your own life has a higher priority than your projects, and it's completely fine if you do not push any commits for the next month.

But generally speaking, you do not need to implement the logic part through CSS. The conditions when to place the "fake dark" can be set via Java first, thus only inserting "fake Dark CSS" if the conditions are met.

Of course, that comes with complexity as well as increasing the possibility of bugs. It also won't be 100 % correct. It is a "feasible estimate", or an heuristic approach if one wants to call it that way.

That also means that there are valid reasons to not implement it at all. Especially taking in consideration the amount of time you have to put into implementing a near-complete "fake dark" which won't be used anymore if Google updates their Androidx library to include the original method back again (hopefully).

In corporate language, we'd call it "it's not feasible to invest more time and resources in this, so it won't be implemented". Which is fine. As a "product owner", that's up to your judgement

P.S.: I hope the chemo helps. With a family friend of mine, it helped her and she has gotten rid of cancer. So, it's not always as "useless" as the probability rate suggests. Stay strong!

 

[M66B]

Of course, you should be with your mother. Me suggesting something doesn't mean I expect you to commit something the next hour. Your own life has a higher priority than your projects, and it's completely fine if you do not push any commits for the next month.

But generally speaking, you do not need to implement the logic part through CSS. The conditions when to place the "fake dark" can be set via Java first, thus only inserting "fake Dark CSS" if the conditions are met.

Of course, that comes with complexity as well as increasing the possibility of bugs. It also won't be 100 % correct. It is a "feasible estimate", or an heuristic approach if one wants to call it that way.

That also means that there are valid reasons to not implement it at all. Especially taking in consideration the amount of time you have to put into implementing a near-complete "fake dark" which won't be used anymore if Google updates their Androidx library to include the original method back again (hopefully).

In corporate language, we'd call it "it's not feasible to invest more time and resources in this, so it won't be implemented". Which is fine. As a "product owner", that's up to your judgement

P.S.: I hope the chemo helps. With a family friend of mine, it helped her and she has gotten rid of cancer. So, it's not always as "useless" as the probability rate suggests. Stay strong!

We still have some hope. The possibility of radio therapy was a positive surprise.

I would like to implement a "fake dark" for Android before version 10, but I am afraid it will be hit and miss. Setting conditions in Java means parsing and evaluating both CCS and HTML, in other words this will be rather complex (like a browser).

 

[mkasimd]

We still have some hope. The possibility of radio therapy was a positive surprise.

I would like to implement a "fake dark" for Android before version 10, but I am afraid it will be hit and miss. Setting conditions in Java means parsing and evaluating both CCS and HTML, in other words this will be rather complex (like a browser).

True that. If the sender applied the background on the body Tag only, it'd be somewhat manageable to check the HTML and CSS for the background's value, but it's also quite possible that the sender used various div or span levels, and the background styling within the div or span or within the CSS for the div or span. Looking into the various levels of div and span to determine whether it virtually covers most parts of the message will be very complex.

But without doing that, it'd be a solution that somewhat works sometimes, but won't work properly many other times. Or you'd have to parse the HTML and CSS similarly to how a browser does, as you rightly describe.

You coded a great mobile alternative to Thunderbird, but no need to compete with Mozilla on the browser front as well, right?

Jokes aside, browsers indeed are highly complex pieces of software. Perhaps you could add an FAQ pointing to this XDA thread showing why the dark mode doesn't work in the original message view for Android 9 and lower as well as why you cannot just implement an own alternative to it. That would at least answer:

• Why doesn't it work? (Google removed the required method from the Androidx libraries, so the dark mode is only available within the libraries available since Android 10 now)
• Why can't you re-implement it? (You'd have to virtually parse the entire HTML & CSS for this to work properly. That's rather complex, similar to a browser. So, it's just not feasible to implement it)
• Will Google re-introduce the removed method? (You have asked Google about it and hope they will, but it's not likely to happen if the removal was intentional)

Maybe even just un-crossing FAQ #81 and writing it there?

P.S: I can also add it into the FAQ and send a pull request, if you can't do it in the next few days.

 

[M66B]

True that. If the sender applied the background on the body Tag only, it'd be somewhat manageable to check the HTML and CSS for the background's value, but it's also quite possible that the sender used various div or span levels, and the background styling within the div or span or within the CSS for the div or span. Looking into the various levels of div and span to determine whether it virtually covers most parts of the message will be very complex.

But without doing that, it'd be a solution that somewhat works sometimes, but won't work properly many other times. Or you'd have to parse the HTML and CSS similarly to how a browser does, as you rightly describe.

You coded a great mobile alternative to Thunderbird, but no need to compete with Mozilla on the browser front as well, right?

Jokes aside, browsers indeed are highly complex pieces of software. Perhaps you could add an FAQ pointing to this XDA thread showing why the dark mode doesn't work in the original message view for Android 9 and lower as well as why you cannot just implement an own alternative to it. That would at least answer:

• Why doesn't it work? (Google removed the required method from the Androidx libraries, so the dark mode is only available within the libraries available since Android 10 now)
• Why can't you re-implement it? (You'd have to virtually parse the entire HTML & CSS for this to work properly. That's rather complex, similar to a browser. So, it's just not feasible to implement it)
• Will Google re-introduce the removed method? (You have asked Google about it and hope they will, but it's not likely to happen if the removal was intentional)

Maybe even just un-crossing FAQ #81 and writing it there?

P.S: I can also add it into the FAQ and send a pull request, if you can't do it in the next few days.

Use FAQ to explain removal of algorithmic darkening · M66B/[email protected]

Fully featured, open source, privacy friendly email app for Android - Use FAQ to explain removal of algorithmic darkening · M66B/[email protected]

github.com

Updated FAQ:

https://github.com/M66B/FairEmail/blob/master/FAQ.md#user-content-faq81

The fake dark option keeps being available though (edit: default disabled).

 

[M66B]

@Marcel: Thank you for your report. We will re-instate the old behavior on pre-Q devices, meaning that calls to setForceDark will work on those devices. This fix will roll out in Webview version 105.

Google Issue Tracker

issuetracker.google.com

 

[M66B]

The next version will have a new option "Delay notifications when Android Auto is connected". Notifications will be delayed until Android Auto disconnects, so you can drive without distractions.