-
Notifications
You must be signed in to change notification settings - Fork 109
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
ui: Implement dark theme #95
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
An implementation note: For all the colors that we have that don't correspond to anything in particular in the Material Design That will let us neatly bundle together a number of colors for a light theme, and corresponding colors for a dark theme, and switch between themes centrally — and even transition smoothly between them when the theme changes, which e.g. the user might have chosen in system settings to have happen on a daily cycle. In short it means we'll use the same nice mechanics that Flutter's Material implementation uses, but for areas that needn't have any design elements in common with Material. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
@Syrineladeb02 Please see our guide to picking an issue to work on: |
It should now be easy to drop in natural dependencies of our content widgets, such as a ThemeExtension for custom light- and dark-theme colors, for all the tests of our Zulip content widgets. To do that, we can just add unconditional code to this function. After this change, some ad-hoc `tester.pumpWidget` calls do remain in this file; see tests of RealmContentNetworkImage and AvatarImage. But those aren't "Zulip content widgets" in the same sense as most of the widgets in lib/widgets/content.dart, which are used exclusively to render parsed Zulip Markdown. (There isn't even any Zulip Markdown that would produce an AvatarImage.) So, leave them be. Perhaps these widgets belong in some other file. Related: zulip#95
This gives a path forward for dark theme (zulip#95), even with the open question we commented about in the previous commit.
This gives a path forward for dark theme (zulip#95), even with the open question we commented about in the previous commit.
…sign From discussion: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/design.3A.20colors/near/1801938 and the Figma linked there: https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=2074%3A26325&t=rjuqcQaHMiGBUReF-1 Now, the app-bar bottom border is colored by the new Figma's `border-bar`, and the main background color is `bg-main`. The app bar background is unchanged because it already matches `bg-top-bar`. And all these color variables have dark-theme variants! (See discussion for what those are.) That'll help when we implement dark theme, zulip#95.
Related: zulip#95 In these places, I was unable to find a specific dark-theme color by consulting web or the Figma (as it is now).
In these places, I was unable to find a specific dark-theme color by consulting web or the Figma (as it is now). Related: zulip#95
In these places, I was unable to find a specific dark-theme color by consulting web or the Figma (as it is now). Related: zulip#95
…sign From discussion: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/design.3A.20colors/near/1801938 and the Figma linked there: https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=2074%3A26325&t=rjuqcQaHMiGBUReF-1 Now, the app-bar bottom border is colored by the new Figma's `border-bar`, and the main background color is `bg-main`. The app bar background is unchanged because it already matches `bg-top-bar`. I've labeled these values with comments in the code. And all these color variables have dark-theme variants! (See discussion for what those are.) That'll help when we implement dark theme, zulip#95.
…sign From discussion: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/design.3A.20colors/near/1801938 and the Figma linked there: https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=2074%3A26325&t=rjuqcQaHMiGBUReF-1 Now, the app-bar bottom border is colored by the new Figma's `border-bar`, and the main background color is `bg-main`. The app bar background is unchanged because it already matches `bg-top-bar`. I've labeled these values with comments in the code. And all these color variables have dark-theme variants! (See discussion for what those are.) That'll help when we implement dark theme, zulip#95.
With the code-block span styles all bundled together in a new CodeBlockTextStyles class, it'll be convenient to make separate `light` and `dark` constructors toward zulip#95 dark theme. Next, we'll pass a BuildContext to the CodeBlockTextStyles constructor, in order to use weightVariableTextStyle for the spans that are supposed to be bold. (The code-block font, Source Code Pro, is variable-weight.) This would have been possible before the current refactor, of course, but this way the spans don't have to repeat the weightVariableTextStyle computations on-demand. They can instead just look up the result from this central source. Related: zulip#95
With the code-block span styles all bundled together in a new CodeBlockTextStyles class, it'll be convenient to make separate `light` and `dark` constructors toward zulip#95 dark theme. Next, we'll pass a BuildContext to the CodeBlockTextStyles constructor, in order to use weightVariableTextStyle for the spans that are supposed to be bold. (The code-block font, Source Code Pro, is variable-weight.) This would have been possible before the current refactor, of course, but this way the spans don't have to repeat the weightVariableTextStyle computations on-demand. They can instead just look up the result from this central source. Related: zulip#95
With the code-block span styles all bundled together in a new CodeBlockTextStyles class, it'll be convenient to make separate `light` and `dark` constructors toward zulip#95 dark theme. Next, we'll pass a BuildContext to the CodeBlockTextStyles constructor, in order to use weightVariableTextStyle for the spans that are supposed to be bold. (The code-block font, Source Code Pro, is variable-weight.) This would have been possible before the current refactor, of course, but this way the spans don't have to repeat the weightVariableTextStyle computations on-demand. They can instead just look up the result from this central source. Related: zulip#95
With the code-block span styles all bundled together in a new CodeBlockTextStyles class, it'll be convenient to make separate `light` and `dark` constructors toward #95 dark theme. Next, we'll pass a BuildContext to the CodeBlockTextStyles constructor, in order to use weightVariableTextStyle for the spans that are supposed to be bold. (The code-block font, Source Code Pro, is variable-weight.) This would have been possible before the current refactor, of course, but this way the spans don't have to repeat the weightVariableTextStyle computations on-demand. They can instead just look up the result from this central source. Related: #95
We'll want to get these colors from theme data, soon, for zulip#95 (supporting dark theme).
Instead of putting them in Subscription model objects. This helps toward zulip#95 by bundling this with our other ThemeExtensions that will switch together between light and dark variants when the theme changes. It's also just nicer to separate this very UI-focused code out of api/model/ (zulip#393). Not marking [nfc] just because of differences in caching logic, although I don't expect a user-visible perf effect. Related: zulip#95 Fixes: zulip#393
Instead of putting them in Subscription model objects. This helps toward zulip#95 by bundling this with our other ThemeExtensions that will switch together between light and dark variants when the theme changes. It's also just nicer to separate this very UI-focused code out of api/model/ (zulip#393). Not marking [nfc] just because of differences in caching logic, although I don't expect a user-visible perf effect. Related: zulip#95 Fixes: zulip#393
The user should be able to choose from these three options for the app's appearance:
Flutter's Material Design implementation paves the way to a pretty good 1.0 version of a dark theme, for the boring, simple bits of UI we paint with
Theme.of(context).colorScheme
. For example, here's the result of just this simple change:For the message list, though, we don't draw from
Theme.of(context).colorScheme
, so it doesn't respond to settingBrightness.dark
there:Probably we should bundle all the message list's light-theme colors into a palette called
messageListColors
or something, then create a version of that palette for dark theme.The text was updated successfully, but these errors were encountered: