Some strings are similar.

I propose we use the LocalSettings.name to help distinguish them.

Final result.

subtitle: Text(
  localSettings[index].name
    .replaceFirst('_', '')
    .replaceAll(RegExp(r'setting|general|gesture'), '')
    .replaceAll('_', ' ')
),

@hjiangsu @machinaeZER0 @micahmo thoughts.

I propose we use the LocalSettings.name to help distinguish them.

Unfortunately the names are not translated (and neither are the labels). I think we need a more general way to assign the translated label to the setting enum. Then we can also assign a category and sub-category. Once that's done, you can display search results like this:

Category -> Sub-Category -> Setting name

For an example:

Floating Action Button > Feed > Back To Top

We started a discussion here but it didn't get very far. 😊

P.S. Thank you so much for working on this, it's something I've wanted for a while!

I love this idea! Guess I never noticed this behavior since I hadn't used the search bar for this purpose. We're pretty sure we wouldn't want to take the strings as a stopgap solution, given the translation issue? I do agree that @micahmo 's solution is probably the best final course of action, and if an interim solution would be messier/create unnecessary work then maybe it does make sense to wait. The issue is real, but I guess is more of an annoyance for now?

Unfortunately the names are not translated (and neither are the labels). I think we need a more general way to assign the translated label to the setting enum.

I've added that in #1045. This only has mapping for the LocalSettings localizations, but we can also add mappings to category/subcategory. Let me know if this solution works! This is the general idea I have for how to do the category/subcategory.

app_en.arb

{
  "defaultFeedType": "Default Feed Type",
  "general": "General",
  "feedTypeAndSorts": "Default Feed Type and Sorting"
}

local_settings.dart

enum LocalSettings {
  defaultFeedListingType(
    name: 'setting_general_default_listing_type',
    key: 'defaultFeedType',
    categoryKey: 'general',
    subcategoryKey: 'feedTypeAndSorts'
  );

  const LocalSettings({
    required this.name,
    required this.key,
    this.categoryKey,
    this.subcategoryKey,
  });
}

Here's an example of how you would get a localized string.

List<LocalSettings> localSettings = [
  LocalSettings.defaultFeedListingType,
  LocalSettings.defaultFeedSortType,
  ...
];

final l10n = AppLocalizations.of(context)!.
Text(l10n.getLocalSettingLocalization(localSettings[0].key)); // Retrieves "Default Feed Type"
Text(l10n.getLocalSettingLocalization(localSettings[0].categoryKey)); // Retrieves "General"
Text(l10n.getLocalSettingLocalization(localSettings[0].subcategoryKey)); // Retrieves "Default Feed Type and Sorting"

Once 1045 Is merged , I'll make the necessary changes.

Once #1045 Is merged , I'll make the necessary changes.

It should be merged now! I was just finishing up the first pre-release for 0.2.9 first before merging this one in.

Hey I just tested out this feature. Again, it's super awesome and something I've wanted for a while. Here are a few observations from my testing.

• The animation between the search widget and the search page is a tiny bit funny to me.
• If you have typed something into the search bar and then navigate back, and then into the search page again, the search text remains (is that intentional, or should we clear it?).
• The main search widget is typeable, and the text stays there, and it is not in sync with the search page. This can cause funny results when typing, because it'll add a letter to the main widget, then open the page, then append the letter to what was previously searched.
• Options that are not real "settings" (like the import action) are not searchable.
• If the result is off the page, it might not be obvious. I've seen other apps scroll to the setting and also flash it.
• Nested settings (like post appearance) are not searchable.

Note that these are just my observations and I haven't reviewed the code yet. Also I'm not asking you to change/fix anything. Just making notes. 😊

The animation between the search widget and the search page is a tiny bit funny to me.

Im using the default animation provided by the SearchAnchor

If you have typed something into the search bar and then navigate back, and then into the search page again, the search text remains (is that intentional, or should we clear it?).

Its Intentional. e.g On android devices settings.

If the result is off the page, it might not be obvious. I've seen other apps scroll to the setting and also flash it.

Currently I don't have a clear way to implement this. I'll need some help.

Nested settings (like post appearance) are not searchable.

I reckon this are searchable e.g Comments from the video

Options that are not real "settings" (like the import action) are not searchable.

This are not in the LocalSettings . I'll add them.

The main search widget is typeable, and the text stays there, and it is not in sync with the search page. This can cause funny results when typing, because it'll add a letter to the main widget, then open the page, then append the letter to what was previously searched.

Didn't get this.

The animation between the search widget and the search page is a tiny bit funny to me.

Im using the default animation provided by the SearchAnchor

Ok if you're using something built-in then there's probably not much you can do about it. 😊

If you have typed something into the search bar and then navigate back, and then into the search page again, the search text remains (is that intentional, or should we clear it?).

Its Intentional. e.g On android devices settings.

Just for reference, my Android device settings search does not persist the search query (although it does have a history).

The main search widget is typeable, and the text stays there, and it is not in sync with the search page. This can cause funny results when typing, because it'll add a letter to the main widget, then open the page, then append the letter to what was previously searched.

Didn't get this.

Here is a demo of what I mean. It is odd to me that I can type in the main search widget, since it seems like it's only supposed to open the page. It's even more weird that the text is not in sync. I would say either typing there should not be allowed, or the text should be appended to the page. Another thing that might help is closing the keyboard when navigating back.

Thanks for doing this again @ggichure! It looks pretty awesome.

If the result is off the page, it might not be obvious. I've seen other apps scroll to the setting and also flash it.

I believe we can split this off for a future enhancement, since it looks like it might take some more work to implement this feature.

If you have typed something into the search bar and then navigate back, and then into the search page again, the search text remains (is that intentional, or should we clear it?).

Personally, I think we should clear it and reset the state. To me, that makes the most sense since navigating out of the search page means I'm done with changing whatever setting I meant to change in the first place.

The animation between the search widget and the search page is a tiny bit funny to me.

The main search widget is typeable, and the text stays there, and it is not in sync with the search page. This can cause funny results when typing, because it'll add a letter to the main widget, then open the page, then append the letter to what was previously searched.

I think this is following material's guidelines here: https://m3.material.io/components/search/overview. It looks like the main search text is supposed to be a text hint, rather than a dynamic traditional search bar. Maybe we can make it more apparent by not showing the cursor blink indicator.

It looks like the main search text is supposed to be a text hint, rather than a dynamic traditional search bar. Maybe we can make it more apparent by not showing the cursor blink indicator.

Makes sense! Although see my last video demonstrating how you can type in it.

Also, would it make sense to remove the elevation here and on the search page to look a little more material?

• No longer persisting the search view
• On back, hide keyboard and unfocus the searchbar .
• Set searchbar elevation to 0 and used surfaceVariant as the barBackgroundColor.

@ggichure I love the latest demo, nice work! 🥳

LGTM now!

@ggichure Is it ready to be merged?

Yes.