Skip to content
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

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

PIG208
Copy link
Member

@PIG208 PIG208 commented Dec 17, 2024

Work towards #97.

Fixes #1216;
Fixes #1228.

screenshots
non-default default

@PIG208 PIG208 force-pushed the pr-settings branch 3 times, most recently from 370a328 to e91e9d5 Compare December 17, 2024 00:28
@gnprice
Copy link
Member

gnprice commented Dec 17, 2024

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.

Copy link
Member

@gnprice gnprice left a 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.

Comment on lines +142 to +155
from2To3: (m, schema) async {
await m.createTable(schema.globalSettings);
},
from3To4: (m, schema) async {
await m.addColumn(
schema.globalSettings, schema.globalSettings.browserPreference);
Copy link
Member

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.

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.
Copy link
Member

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.

Comment on lines +7 to +10
# Generated code from drift can contain unused local variables.
- lib/model/database.g.dart
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Collaborator

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?

Copy link
Member Author

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.

Comment on lines 46 to 52
/// 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 {
Copy link
Member

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.

@PIG208 PIG208 changed the title wip; Store some client settings Support some client settings; add settings page Feb 21, 2025
@PIG208 PIG208 marked this pull request as ready for review February 21, 2025 00:32
@PIG208 PIG208 added the maintainer review PR ready for review by Zulip maintainers label Feb 21, 2025
@PIG208 PIG208 requested a review from chrisbobbe February 21, 2025 00:37
Copy link
Collaborator

@chrisbobbe chrisbobbe left a 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?

Comment on lines +7 to +10
# Generated code from drift can contain unused local variables.
- lib/model/database.g.dart
Copy link
Collaborator

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?

Comment on lines -485 to +486
.single.equals((url: Uri.parse(expectedLaunchUrl), mode: LaunchMode.platformDefault));
.single.equals((url: Uri.parse(expectedLaunchUrl), mode: LaunchMode.inAppBrowserView));
Copy link
Collaborator

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.
Copy link
Collaborator

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

Comment on lines 224 to 228
// 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),
Copy link
Collaborator

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?

Copy link
Member Author

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).

@@ -97,6 +100,27 @@ void main() {
check(() => a.lerp(b, 0.5)).returnsNormally();
});
});

testWidgets('follow globalSettings.themeSetting if not unset', (tester) async {
Copy link
Collaborator

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 {
Copy link
Collaborator

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]>
A builder is needed when themeData needs to access GlobalStore through
the BuildContext from the builder.

Signed-off-by: Zixuan James Li <[email protected]>
@chrisbobbe
Copy link
Collaborator

Oh, and we have an issue for the theme setting 🙂 so the PR description and relevant commit can be marked as fixing that:

@PIG208
Copy link
Member Author

PIG208 commented Feb 25, 2025

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.

@PIG208 PIG208 requested a review from chrisbobbe February 25, 2025 00:17
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]>
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]>
@chrisbobbe
Copy link
Collaborator

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.

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?

@PIG208
Copy link
Member Author

PIG208 commented Feb 25, 2025

Opened #1375.

@PIG208
Copy link
Member Author

PIG208 commented Feb 26, 2025

Forgot to post a message here. This PR is ready for review.

what UI text does zulip-mobile use for the browser setting? Would it make sense to copy that?

Good point! The string is "Open links with in-app browser"; switched to that instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintainer review PR ready for review by Zulip maintainers
Projects
None yet
3 participants