Dark theme setting is not available

[xf-]

Threema looks unfamiliar with a white theme. Synchronize the theme.

[rugk]

But preferably make it possible to switch the setting on the desktop independently from the app. Users may want to use a dark Threema App and a white Threema Web (or vice versa).

[xf-]

@rugk i thought the same, but there is no settings area available in web. It needs to be stored on the phone for better usability with multiple devices or outdated sessions.
First step is synchronization easier, but a setting would be great :)

[rugk]

I think storing this setting could be done in different ways:

• locally in the browser (aka local storage), possibly encrypted with the password
• on the device (thus the setting would be the same for every web client connected)
• on a new connection default to the setting of the app and show switch in the web client for (temporarily) switching the design

The first and last thing can of course be combined, so that permanent session store the setting while temporary session always use the one from the app.

[FloThinksPi]

Hey guys, i worked some basic stuff out and Implemented a prototype over the local Storage. Tell me what you think about it. https://github.com/FloThinksPi/threema-web.
It does not apply the Themes on every element atm, i guess HTML and CSS need some tags but i have no time left today to look into that. Also the changes get not applyed directly on the Settings Dialog but yea 😋

[dbrgn]

@FloThinksPi cool! If you create a pull request (can also be marked as work in progress) we can give you feedback on it :)

Regarding storage of the settings:

• Local storage is generally a good idea.
• We could store the settings together with the keys (encrypted with the password), but that would mean that the settings are only persisted when using stored sessions.
• Storing them separately, settings can be persisted independent of the session. That would also mean that synchronizing web theme and app theme is tricky though, because it's unclear when to override user defined settings.

Maybe @sillych has an opinion on that.

[rugk]

IMHO a good solution would be to sync the setting for temporary sessions and offer a switch in the web UI to change the theme. This switch should however not save any data and only apply to the current session.
When using a persistent session the setting can be changed encrypted in local storage. In this case it would not be synced with the app.

Or you just do it as you said and store it unencrypted in local storage (not nice, but not a problem since the data is really not useful to an attacker) and do not sync it with the app.

IMHO it's your decision.

[FloThinksPi]

Hey @rugk and @dbrgn, thansk for the response and ideas.

In my Opinion users often considder the Webapp as standalone application and dont know about how strongly connected The actuall app and the webapp are.
In my opinion storing settings per client/browser leads to a native experience, because i think users dont expect settings to sync with those from the android app.
Also some features that exist in the webapp probably will not exist in the android app so this would lead to inconsistency while syncing the settings.

One possibility to sync the Webapp Settings between sessions would be to store the raw data on the android app, as alternative to the localstorage which would just persist settings per Browser.

While looking at web.whatsapp, they also offer changing the backgrounds of chats, which is probably done in local/session storage and dont sync that with the android apps settings.
Edit: they actually just save the json to local storage like that [{"id":"defaultPreference","wallpaperColor":"default_chat_wallpaper"}]

As for security at this state i would save the settings unencrypted , because it does not contain any important data(only theme name atm), this also avoids the Problem with the requirement of the password to encrypt. The systems stays extendable trough the settingsService so once critical stuff has to be saved in storage, someone could think about a way to encrypt the settings data and just has to change the SettingsServices save functions. Also the settingsData can be synced with the device there but for the first implementation i would go with the localstorage .

Will send you a pull request later when i am back home. :)

[joelfischerr]

@FloThinksPi are you still working on this?
Because if not I might try to take a stab at it as soon as the iOS beta is released :)

[FloThinksPi]

Hi @joelfischerr , no i am Not. Unfortunally i have no time for this atm . But IT would be Nice to See dark Theme Coming :)

[joelfischerr]

In #110 (comment) it was suggested to use CSS instead of Angular for changing themes.

But when using CSS instead of Angular for the changing the theme how can the material directives be updated? I haven't really found a way that works.

For example I couldn't find a way to change the colour of the text in the password input field in the welcome screen.

[dbrgn]

For example I couldn't find a way to change the colour of the text in the password input field in the welcome screen.

What about #welcome .password-entry input { color: green; }?

Edit: And if you're talking about the placeholder text, see https://stackoverflow.com/questions/2610497/change-an-html5-inputs-placeholder-color-with-css

[joelfischerr]

Thanks a lot!

That still left the line below the input, but I was able to solve with this https://stackoverflow.com/questions/32585442/change-angular-material-input-style#32586869.

[joelfischerr]

Just to make sure that I'm not getting completely offtrack, is this (_dark.scss) somewhat close to the general structure you described in #110 (comment)?

[dbrgn]

@joelfischerr yes, this doesn't look bad!

I am currently thinking about how maintainable something like that will be. I like how you put all variables at the top. However, class names might change without someone noticing that one of the available themes broke.

Maybe the best solution would be to make all used colors context-specific variables, so that the entire color configuration would be in _themes/light.sass? That would allow people to create themes simply by copying that file and overriding the color variables. This is similar to how Mattermost does themeing.

[joelfischerr]

It's most likely not very maintainable and copying the whole structure of the css files into the theme files is (at least to me) cumbersome and prone to error. But I think I might have found a possibly better approach as described in webdesign.tutsplus.com.

I took a slightly different approach to what is described above to create one css file for all themes instead of one css file for every theme.
All colours defined in _colors.scss are defined as !default which then allows them to be overwritten in the theme files. I tried this in joelfischerr@a060364 and it seems to work.

This way we would increase the maintainability, as only new scss files would need to be imported into all the theme files. But the size of app.css would increase linearly in the number of themes, which might not be desirable.

[dbrgn]

Interesting, I didn't know !default. I had a similar idea in mind, but with a different loading strategy:

• All theme-specific stuff should be put into variables. For example, instead of using background-color: white we'd use background-color: $background-color.
• A theme is an SCSS file that simply sets all those variables. Probably by using !default.
• Right now we have a single app.scss. We'd simply add a app-light.scss and a app-dark.scss file that import both app.scss followed or preceded by the theme overrides. We'd then build those themes in parallel into separate CSS files.
• The CSS is not loaded directly in the HTML, but instead injected from JS conditionally in very early initialization code of the application. The theme preference is stored in localstorage, so that the loading code can check the preference before loading the CSS, avoiding having to load multiple themes without using them all.

This is just a rough idea, what do you think @joelfischerr?

[joelfischerr]

That is almost what I had in mind.

A theme is an SCSS file that simply sets all those variables. Probably by using !default.

With a separate css file being generated for each theme we shouldn't need !default. Unless we want to keep using _colors.scss as basis for the colours, which in my opinion is a good idea as it would give a central file with all colours. This would increase the clarity in case the theme files were to get inconsistent in the future.

I have tried to do a quick draft of what you have described in joelfischerr@42f123b. It seems to work and is most likely clearer and more maintainable than the first approach.

I'm not sure what the benefits of each approach are. But the second one seems to have the following benefits:

• More maintainable as the only thing that potentially needs to be changed are the colours. Which results in the same effort as right now.
• Creating new SCSS files only requires adding them in the app.scss and not in all theme files. Which results in the same effort as right now.
• Smaller file sizes could mean better performance.

I'd adapt your idea to

• All theme-specific stuff should be put into variables. For example, instead of using background-color: white we'd use background-color: $background-color.

• The default theme is defined in _colors.scss. All colours (using !default) and images used throughout Threema Web should be defined here.
• Nothing is using their default colour (especially things from AngularJs). Colours of all elements are set in the respective SCSS file.
• A theme is an SCSS file that simply sets overrides all those variables. Probably by using !default.

• Right now we have a single app.scss. We'd simply add a app-light.scss and a app-dark.scss file that import both app.scss followed or preceded by the theme overrides. We'd then build those themes in parallel into separate CSS files.
• The CSS is not loaded directly in the HTML, but instead injected from JS conditionally in very early initialization code of the application. The theme preference is stored in localstorage, so that the loading code can check the preference before loading the CSS, avoiding having to load multiple themes without using them all.

This would result in the following task list:

Todo

• Decide which approach to take.
• Extract all relevant colours into _colors.scss.
• Define colours for all elements. Especially elements from AngularJS. Note all elements that were assigned a colour.
• Maybe consolidate colours into a few distinct ones. E.g. white, greyish-with and very light grey could all be the same colour.
• Move the preference logic out of notification.ts and into a separate file. Possibly with a settings controller for shared code between notification.ts and theme.ts. I.e. settingsController.ts is used in notification.ts and theme.ts to write to and read from the local storage.
• Create a light and a dark theme as in Threema for Android.
• Add item in the settings to set the theme.
• Theme is not loaded/applied in "Verbindung wiederaufbauen" view

[dbrgn]

@joelfischerr thanks for the writeup 🙂 would you like to give it a try?

Some notes:

The default theme is defined in _colors.scss

I think I'd name the theme file clearly, e.g. themes/_light.scss.

Define colours for all elements. Especially elements from AngularJS.

I wouldn't overdo this. Only add a variable if you really need to change it in a different theme.

Move the preference logic out of notification.ts and into a separate file

That's a good idea. That file could be responsible for fetching and setting preferences.

Possibly with a settings controller for shared code

Not a controller, but either a service or -- if it uses only very little AngularJS specific code -- a plain TypeScript class or function collection.

Btw, we have recently added a way to test non-Angular TypeScript code: https://github.com/threema-ch/threema-web/tree/ios/tests/ts I now prefer to put things like utility functions in plain TypeScript files, instead of AngularJS files, it's more portable.

[joelfischerr]

Yes, I think it would be a good first contribution. But I can't promise to be able to do more than to try. I haven't worked much with neither css nor TypeScript/JavaScript.

I think I'd name the theme file clearly, e.g. themes/_light.scss.

I meant to keep the _colors.scss file in sass/base/ in order to keep the base theme organised there. This would allow us to pick the colours the themes are allowed to change, as I don't think the color of the icon or the work indicator should changeable.
Not defining those colours as !default in sass/base/_colors.scss would give an error when someone tries to change that colour in a theme.
The themes themselves should then of course be organised in a clearly labeled folder.

Not a controller, but either a service or -- if it uses only very little AngularJS specific code -- a plain TypeScript class or function collection.

I'm sorry, I wasn't aware of the special meaning of controller. When I said controller I meant service.

I'll try to keep the Todolist here up to date.

[lgrahl]

@joelfischerr Any updates on this? We would like to address #31 but want to wait for this change since fixing #31 completely would require rewriting some portions of the SCSS files. 😃

[joelfischerr]

I have a very rough first draft almost ready, but I also have exams throughout August which means I might not be able to finish this until the end of September.

And since this is my first contribution, I think I'd be more comfortable if you didn't wait for me and went ahead with #31. Additionally, it's probably not a lot more effort to adjust my code after #525 has been merged than it is to adjust it now.

In my opinion the only downside with going ahead with #31 is that the newly created variables for the colours might not be perfect for theming or that creating variables for the colours would need to be taken out of #525.

[lgrahl]

Sorry for the delay. If you have something working, you can already create a PR and rebase once we have merged #525. (PRs are easier to track than the gazillions of issues.)

[joelfischerr]

I have a rough but working version. Should I already create a PR just to make sure I'm working towards the right direction?

[rugk]

You can also make use of this new thing to automatically switch to the dark mode or vice-versa:

There is a quite new CSS media query feature called prefers-color-scheme. It allows you to detect whether the system/user wants a dark website, so you can adjust your CSS.

Currently it is only supported by Safari and Firefox 67 or higher.

BTW: I also have a Firefox add-on called “Dark Mode Website Switcher” (source code) that you can use to toggle this setting in Firefox directly – without needing to change the system option. Maybe that could be helpful.

---

I don't know what the current state of discussion (or of PR #763) is, but IMHO it should determine whether to use dark or light mode based in this order:

• if saved locally in Threema Web (= user changed option in settings) use this mode
• if not, by default use prefers-color-scheme, if possible
• if prefers-color-scheme is not supported: use mode that is set in Threema app(?)
• (and AFAIK in newer Android versions) the Threema app itself triggers/determines/can check the dark mode via a system setting on Android

This makes sense, because the screens of the app (called "remote" now) and the desktop (called "locally") are totally disconnected (literally, actually 😉), so I may have a dark mode there or somewhere else, so the "generalized" order is:

• user-set, locally
• system, locally
• user-set, remote
• system, remote

This also still allows users to override the system setting at any time, while using good defaults based on the system setting.

[Bond246]

Hi,

what is the status of this?
#763 looks like that the dark mode is finally coded.

But i can't find an option or have a synced dark mode anywhere.

Thanks

[lgrahl]

Threema Web is in maintenance mode while we are working on a new solution that should resolve some of the long-standing issues we were having with Threema Web. The replacement will likely ship directly with light and dark themes.

[realpixelcode]

Threema Web is in maintenance mode while we are working on a new solution that should resolve some of the long-standing issues we were having with Threema Web. The replacement will likely ship directly with light and dark themes.

Nice to hear that! I'm really excited already ☺️ Then we can also make use of @rugk's nice browser addon Dark Website Forcer

[rugk]

You can yeah. Just saying as it is stated there that the website of course has to support that (CSS) feature to work… 😊

[widardd]

any news on this?

[xf-]

i think this is obsolete. With new multi device stuff announced the web client in this from is obsolte

[dbrgn]

any news on this?

No, please read the comment from @lgrahl above. Threema Web is in maintenance mode while we are working on a new solution that should resolve some of the long-standing issues we were having with Threema Web. We will still do regular maintenance and fix critical bugs, but for now there will be no major new features or non-critical bugfixes. See #996 for more details.

Since a dark theme is a lot of integration- and testing-effort (even if contributed by a user), there will not be a dark theme for Threema Web.

However, the solution that will replace Threema Web (see https://threema.ch/en/blog/posts/md-architectural-overview) will very likely ship with a dark theme from the start.

[MaggiWuerze]

Is there something like a rough ETA for this new Threema Web Client? I assume the new Electron based client is simply a web wrapper and has nothing to do with the new solution.

[lgrahl]

I assume the new Electron based client is simply a web wrapper and has nothing to do with the new solution.

Roughly, yes.

Is there something like a rough ETA for this new Threema Web Client?

Apologies but we will not provide an ETA here. When there's something to announce, it will likely be the done via the official blog.

[Bluscream]

Still no updates a year later? I can't believed i payed for access to this

[xf-]

Yeah, this is a really sad story.

• Started to create support
• Stopped, because of a better replacement of battery draining experience
• ETA in blog was which is currently in development and will become available in the course of 2021 and no update or mention of the project ever again! No information on state or delay/timeframe. Meantime W*App has a beta for standalone (no phone connection) in browser tab running.
• Misspoke - there is small update https://threema.ch/en/blog/posts/threema-for-desktop - No announcement like beta starts Q2 or Q3
  I hope for more communication Everything is better than current web client (especially without Google services) or openmittsu (really nice, but a lot of stuff missing) and not really active

[threema-danilo]

@xf- we are still working on it, and believe me, we all wish it would already have been released 🙂 But we want to make a product that's good, and that takes its time. There will be official communication as soon as the project is ready for a first round of public testing. Thank you for your understanding and patience.

[xf-]

A little more information after first describing the technical side, than a post about new desktop tool and then basically nothing and a post on last day past year and first timeline (sometime in 2021) on Twitter. Afterwards it looked like a project from Google that's added soon to Google graveyard.
Make post about state or features all supported from phone client and maybe small ETA like I wrote Q[1-4] 202\d.

At the moment I try to avoid of threema. Kills the battery with web client and sync without Google services is horrible. Every time activate web session in the app.

[wschlich]

@xf- we are still working on it, and believe me, we all wish it would already have been released slightly_smiling_face But we want to make a product that's good, and that takes its time. There will be official communication as soon as the project is ready for a first round of public testing. Thank you for your understanding and patience.

This issue should be reopened until dark mode is released then!

[threema-danilo]

@wschlich to be clear: This is the issue tracker for Threema Web. Threema Web will never get a dark mode. The work-in-progress Threema Desktop 2.0 (which be available as a web-based version as well) already has a dark mode (but it is not yet ready for publication).

[wschlich]

@threema-danilo Too bad. I dislike all these shitty messenger desktop apps, even more bloat on my laptop :-(

[lgrahl]

Emphasizing quote:

The work-in-progress Threema Desktop 2.0 (which [will] be available as a web-based version as well) already has a dark mode (but it is not yet ready for publication).

Whether or not that will be called "Threema Web 3.0" is unclear atm.

The feature requests still open for 2.x are a good reminder for the successor of Threema Web 2.x. We will eventually transfer those where applicable. Following that rule of thumb: Since the successor already has a dark theme, closing this issue is reasonable. Note that it is a rule of thumb and nothing more. I'm not claiming we have 100% consistency here but no one would benefit from excessive housekeeping at this point in time.

[rugk]

. I dislike all these shitty messenger desktop apps, even more bloat on my laptop :-(

As you may have noticed, it was stated that Threema Desktop will also be available as a web version, so you can also just use your browser – just as you apparently do now, given you somehow came into this repository for Threema Web.

[widardd]

2 years of maintenance mode is a terrible decision. Simple QoL should still be implemented if you're going to have people use a tool for that long IMHO.

[Ammako]

In the meantime, consider https://github.com/openstyles/stylus

For current desktop app, this won't help, but for web users, there's a pretty good dark theme that should do the job for you, until the new app is out.

https://userstyles.org/styles/195963/threema-dark-2021-updated

[xf-]

Maintiance mode started 4,5 years ago:
5385d13

This just a joke draining the battery.
Some Apple stuff was release 2 years ago, no more news or updates. Just silence!

It is time to say goodbye Threema!

[Ammako]

Some Apple stuff was release 2 years ago, no more news or updates. Just silence!

?

https://threema.ch/en/whats-new/desktop-md

[Bluscream]

Why is anyone still using this when signal exists?

[threema-lenny]

Disclaimer: This is total off-topic, just to be clear. I don't want to lock this thread. I understand your frustration but it's no excuse to write destructive comments. I promise I would have given you these insights if you had simply asked.

Yes, the multi-device implementation is still an ongoing process and it still needs work but the Desktop 2.0 solution is very advanced already and works well in combination with iOS (give it a try if you're using iOS). The multi-device implementation in Android is making a lot of progress, too.

A lot of things can be argued, like prioritisation, timing of announcements, the introduction of forward security at this point in time introducing a lot of additional complexity for the multi-device protocol (intrinsically moving the goalpost), the sheer underestimation of the work required in the apps to get it working where we needed to rewrite almost all of the backend code. Mistakes were made. It is what it is.

But we learned a lot and are still 100% committed to get it done.

[Ammako]

It made sense to prioritise iOS, but what's the technical reason why Android users can't have a beta as well by now? That would ease a lot of frustrations.

Would the desktop app really need twice as much work just to support both?

[xf-]

Disclaimer: This is total off-topic, just to be clear. I don't want to lock this thread. I understand your frustration but it's no excuse to write destructive comments. I promise I would have given you these insights if you had simply asked.

Yes, the multi-device implementation is still an ongoing process and it still needs work but the Desktop 2.0 solution is very advanced already and works well in combination with iOS (give it a try if you're using iOS). The multi-device implementation in Android is making a lot of progress, too.

A lot of things can be argued, like prioritisation, timing of announcements, the introduction of forward security at this point in time introducing a lot of additional complexity for the multi-device protocol (intrinsically moving the goalpost), the sheer underestimation of the work required in the apps to get it working where we needed to rewrite almost all of the backend code. Mistakes were made. It is what it is.

But we learned a lot and are still 100% committed to get it done.

I commented on this, because it was closed in favor of new development. 4 years is forever in IT development and after first announcements the communication was gone.
I have no problem with favoring an OS other the other, but cutting anything community related down and no communication or planing to get some kind of relief is a no-go for me.

Remember Threema announced "we get it before the end of the year" and years later nothing changed/was released and this client is just dead as well. No new features like editing messanges or a dark theme and battery drain for free.

[threema-lenny]

It made sense to prioritise iOS, but what's the technical reason why Android users can't have a beta as well by now? That would ease a lot of frustrations.

Would the desktop app really need twice as much work just to support both?

The Desktop 2.0 app does not need to change a single line of code to support Android users. What's actually holding us behind here is the implementation status of the multi-device protocol in the Android app. Development simply started very, very late because we usually took the approach to try a new feature on one platform and then take the learnings to port it to the others. I personally believe that, in retrospective, this was not the right approach for multi-device. That's the primary cause for the status quo with regards to the Android app.

I commented on this, because it was closed in favor of new development. 4 years is forever in IT development and after first announcements the communication was gone.

Right, almost everything of this project was stopped in favour of Desktop 2.0. New features are only supported in very rudimentary form (e.g. messages are flagged as edited but cannot be edited within Threema Web) for a reason. Keep in mind that any resources put into Threema Web take away resources from the multi-device implementation and from Desktop 2.0.

Desktop 2.0 has a dark theme. We had it in mind and designed the app from scratch in a way that supports it from the very beginning.

Remember Threema announced "we get it before the end of the year" [...]

I agree with you that this was miscommunicated. To be 100% transparent with you folks: The sentence you're quoting was added right before release of the blog post without going through the usual review process. It was exceedingly wishful thinking to state it could be done before the end of the year and had a very high chance to disgruntle our userbase if not adhered to, hence why it was removed later. You bringing this up proves that it was a mistake. But like I said - we learned a lot and I'm confident this won't happen again.

[...] and years later nothing changed/was released and this client is just dead as well.

There are two options:

1. Threema can focus on multi-device and supersede Threema Web with Desktop 2.0. Multi-Device resolves the battery drain issue forever, Desktop 2.0 provides a dark theme and has full edit/delete support already.
2. Threema Web development continues, taking away substantial resources from the multi-device development.

We picked the first one. And according to your stated priorities, you would, too. I'm an Android user, so I want multi-device support in the Android app as fast as possible, too.