-
Notifications
You must be signed in to change notification settings - Fork 273
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
Support some client settings; add settings page #1167
base: main
Are you sure you want to change the base?
Conversation
370a328
to
e91e9d5
Compare
Thanks for taking this on! Looking forward to it. One first high-level comment: in the branch we merge, let's have at least one of these two settings get added as its own separate commit, complete with a migration. That way we have a nice demonstration of what it'll look like to add each new setting in the future. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've skimmed now through more of this code. A few other high-level comments below.
from2To3: (m, schema) async { | ||
await m.createTable(schema.globalSettings); | ||
}, | ||
from3To4: (m, schema) async { | ||
await m.addColumn( | ||
schema.globalSettings, schema.globalSettings.browserPreference); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
db: Start generating step by step migration helper
https://drift.simonbinder.eu/migrations/step_by_step/#manual-generation
Hmm, interesting. Yeah, this seems useful — I think this migration to 4 is already an example where this structure lets the new migration get added as just a separate thing, and with the more manual structure we'd have to have logic for it to interact with the migration to 3.
lib/model/schema_versions.dart
Outdated
import 'package:drift/drift.dart' as i1; | ||
import 'package:drift/drift.dart'; // ignore_for_file: type=lint,unused_import | ||
|
||
// GENERATED BY drift_dev, DO NOT MODIFY. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's give this a .g.dart
name, so it's clear in a more uniform way that it's generated.
# Generated code from drift can contain unused local variables. | ||
- lib/model/database.g.dart |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be reported as a bug in Drift — it's fine for the generated code to do this but then it should contain an ignore comment for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filed simolus3/drift#3384 for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That issue has been marked as fixed! 🎉 So can we drop this commit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope that there will be a release with this patch soon (last one was 2 weeks ago). If not we can just ask politely.
lib/model/database.dart
Outdated
/// The visual theme of the app. | ||
/// | ||
/// See [zulipThemeData] for how themes are determined. | ||
/// | ||
/// Renaming existing enum values will invalidate the database. | ||
/// Write a migration if such a change is necessary. | ||
enum ThemeSetting { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's put these enum definitions in a new file lib/model/settings.dart
.
Then that can also be the home of other logic we add in the future for individual settings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is exciting!
One question: what UI text does zulip-mobile use for the browser setting? Would it make sense to copy that?
# Generated code from drift can contain unused local variables. | ||
- lib/model/database.g.dart |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That issue has been marked as fixed! 🎉 So can we drop this commit?
.single.equals((url: Uri.parse(expectedLaunchUrl), mode: LaunchMode.platformDefault)); | ||
.single.equals((url: Uri.parse(expectedLaunchUrl), mode: LaunchMode.inAppBrowserView)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
db: Store browser preference in database
I think these test changes are meant for a later commit:
content: Follow browser preference setting when opening links
(caught with git rebase --exec 'tools/check --diff @~'
)
@@ -76,7 +76,7 @@ abstract class ZulipBinding { | |||
} | |||
|
|||
/// Get the app's singleton [GlobalStore], | |||
/// calling [loadGlobalStore] if not already loaded. | |||
/// loading it asynchronously if not already loaded. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
store [nfc]: Update outdated references to loadGlobalStore
commit-message nit: truncate commit ID to 9 characters
lib/widgets/app.dart
Outdated
// The context has to be taken from the [Builder] because | ||
// [zulipThemeData] requires access to [GlobalStoreWidget] in the tree. | ||
// TODO: any way to remove the [Builder], like how we pulled out | ||
// [_handleGenerateInitialRoutes]? | ||
theme: zulipThemeData(context), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we could have GlobalStoreWidget
take a buildChild
param instead of child
(or support passing one or the other 🤷♂️), and it would pass its own context to buildChild
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Chose to name it builder
to match Builder.builder
and refactored places that use GlobalStoreWidget
(one in lib and a handful in tests).
test/widgets/theme_test.dart
Outdated
@@ -97,6 +100,27 @@ void main() { | |||
check(() => a.lerp(b, 0.5)).returnsNormally(); | |||
}); | |||
}); | |||
|
|||
testWidgets('follow globalSettings.themeSetting if not unset', (tester) async { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
follow globalSettings.themeSetting if not unset
I know what you mean by "if not unset", but it feels slightly unsatisfying: we do still want to follow globalSettings.themeSetting
if it's unset 🙂, but the details are just a bit more complicated for that value.
I also see that this test exercises the "unset" value, but incompletely: with "unset", let's also test that the theme responds when the device setting is changed:
tester.platformDispatcher.platformBrightnessTestValue = Brightness.dark;
await tester.pump();
check(zulipThemeData(element)).brightness.equals(Brightness.dark);
of: find.text('Use external browser'), | ||
matching: find.byType(SwitchListTile)); | ||
|
||
testWidgets('smoke', (tester) async { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's also test that the switch is in the right place, and responds correctly, when the setting hasn't been set yet (the part meant by "effective" in effectiveBrowserPreference
)
We are waiting for the next release that will fix this issue. Signed-off-by: Zixuan James Li <[email protected]>
The name "unset" was chosen instead of "default" because the latter is a keyword. We could write a custom `TypeConverter` to use "default" instead, but `textEnum` is more convenient. Signed-off-by: Zixuan James Li <[email protected]>
These were supposed to be updated in commit fc80be1 where we replaced loadGlobalStore with getGlobalStore. `LiveGlobalBindings.load` is the only thing left analogous to the previously referred to `loadGlobalStore` method. To avoid direct referencce to this specific implementation on `GlobalStore`, mention that loading it for the first time is expected to be asynchronous instead. Signed-off-by: Zixuan James Li <[email protected]>
Later we will add more required parameters to TestGlobalStore. Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
A builder is needed when themeData needs to access GlobalStore through the BuildContext from the builder. Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
Oh, and we have an issue for the theme setting 🙂 so the PR description and relevant commit can be marked as fixing that: |
There is also one for browser: I didn't fix them because they do not implement a final design. Perhaps we can have a new design issue for the settings page. |
This does not aim to fully implement the wip design for the settings page. We offer it mainly to test settings, so the implementation is kept as simple as possible. WIP design: https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=446-21372&t=BZKpTQPSiBDNxwvB-0 Fixes: zulip#1216 Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
This preserves the default behavior (platform-dependent) when the preference is unset. Signed-off-by: Zixuan James Li <[email protected]>
The translation for the label is taken from zulip-mobile. The UI currently does not have a design, and is made to be as simple as possible to implement for now. Fixes: zulip#1228 Signed-off-by: Zixuan James Li <[email protected]>
Sure, that sounds good: a new issue for redesigning the settings page as a whole. Then the individual issues, #1216 and #1228, don't need to stay open to track that redesign, and they can be marked as fixed in this PR; what do you think? |
Opened #1375. |
Forgot to post a message here. This PR is ready for review.
Good point! The string is "Open links with in-app browser"; switched to that instead. |
Work towards #97.
Fixes #1216;
Fixes #1228.
screenshots