[Feature request] Suppress storage capacity warning

[KaKi87]

Hello,

I reached 80% of my storage capacity (400 MB).

Mostly because I imported a lot of attachments from my old Google & Microsoft accounts.

But, I have accumulated this data over years, and am not going to accumulate 100 MB more anytime soon.

Therefore, this warning could be suppressed without causing any problems for a long time, which is why I am requesting this as a feature.

Thanks !

[vladimiry]

The opt-in type of this feature would be somehow complex in implementation/support (optional feature, disabled by default). The hardcoded (enabled to all) is easy to enable, as would be a matter of extending the https://github.com/vladimiry/ElectronMail/tree/master/patches/protonmail patches. But I don't think it's a good idea to enable it to everyone. Given these points, the request gets rejected.

[vladimiry]

By the way, this is an open-source thing. So, if you really need the feature, you could extend the above-mentioned patches in the cloned repo and assembly your own app package.

[KaKi87]

The opt-in type of this feature would be somehow complex in implementation/support (optional feature, disabled by default).

I agree with the fact that it could be optional, but does that really make it complex ? Implementation is just CSS.

By the way, this is an open-source thing. So, if you really need the feature, you could extend the above-mentioned patches in the cloned repo and assembly your own app package.

Despite that fact, using open source as an excuse to replying users with "if you want it do it yourself" is unfriendly.

[vladimiry]

Implementation is just CSS.

You could handle the need on your own then. The app supports custom CSS injection on per account basis. See the respective option on the account edit form.

[KaKi87]

I can't seem to be able to open DevTools though.

[vladimiry]

DevTools suppressed in the app production build. You could debug the stuff in the browser version and then save the final CSS snippets in the app.

Implementation is just CSS.

Btw, using CSS for handling the need won't be a sustainable solution since the potential web client change won't be automatically tracked as to when you use the patching. So if you will be considering providing a pull request, the CSS-based solution won't be accepted.

[KaKi87]

using CSS for handling the need won't be a sustainable solution

Well, 11 months ago, I asked ProtonMail devs to allow marking an email as read on mobile web, and they said they [would] get this fixed in one of the upcoming releases, which never happened.

Therefore, 5 months ago, I looked into this matter myself, and found out that it was just a matter of removing no-mobile classes, so I created a userscript that does just that, and still works today.

[vladimiry]

and still works today.

What I meant is that there is no guarantee that it/userscript-snippet will work after the next web client update, since they can change classes/elements on the page. While the patching will end up with an error if the patched code piece gets changed (if the patching done properly), so it's an automatic web client change tracking (this is why I wrap some code pieces with /* electron-mail mark */ in https://github.com/vladimiry/ElectronMail/tree/master/patches/protonmail). So using stuff like userscript or CSS manipulations is ok if you are ok to manually keep track of the web client updates (unless you implement the e2e tests).

Anyway, you have at lest 2 options of how to handle the need on your own (CSS injection and web client patching).