Closed ThatOneCalculator closed 2 years ago
I have already tried to see what I could change to adapt Material Design 3 but as it stands, M3 seems to be way more limited in design than M2. It takes a lot of the choices you had in M2.
But I'll continue looking into it.
Yea, I see this as being a more down-the-road addition, as (hopefully) by the time 1.0 rolls around, there will be far more options with Material 3
ColorScheme.fromSeed using Kaiteki's pink leaves a lot to be desired.
Well for fromSeed
to look good, the whole UI should use it. I think Aliucord is a good example of this.
Well for
fromSeed
to look good, the whole UI should use it. I think Aliucord is a good example of this.
Uhh, Flutter is technically using it everywhere since the app theme propagates globally throughout the app. This nothing more than a color scheme. I also tried setting useMaterial3
to true
but apparently nothing is happening.
When I say "everywhere", I'm also referring to the accent color and background, which will probably be easier to set once Material Design 3 is better implemented in Flutter.
I found out why useMaterial3
wasn't applied, still mixed feelings though.
Maybe have it toggleable in settings? I actually kinda like it.
Maybe have it toggleable in settings? I actually kinda like it.
The settings are broken lmao.
(I still have nobody who can properly assist me in state management and data persistence)
I wish I could help but I've literally never used dart or flutter before :(
For settings, maybe the key value schema could work?
https://www.raywenderlich.com/5965747-data-persistence-on-flutter
I wish I could help but I've literally never used dart or flutter before :(
For settings, maybe the key value schema could work?
https://www.raywenderlich.com/5965747-data-persistence-on-flutter
I am aware of using shared_preferences to store simple data types as key-value, but it's going to suck real hard later on with more complex settings, as the code maintenance will shoot through the roof. (This is my main gripe with Flutter tutorials and apps, that they don't actually attempt to be massive)
Perhaps with SQLite then? Seems to be better for bigger data. For the one desktop app I've ever written (in Electron), I used key-value stores for settings but SQLite seems to makes more sense for this.
If you are writing an app that needs to persist and query large amounts of data on the local device, consider using a database instead of a local file or key-value store. In general, databases provide faster inserts, updates, and queries compared to other local persistence solutions.
Perhaps with SQLite then? Seems to be better for bigger data.
If you are writing an app that needs to persist and query large amounts of data on the local device, consider using a database instead of a local file or key-value store. In general, databases provide faster inserts, updates, and queries compared to other local persistence solutions.
The problem is that we aren't aiming for storing large amounts of data, or tables. Kaiteki might store several themes, boolean flags, strings, ints, arrays of compound data, etc in the future.
The only thing I can think of then is key-value stores combined with some custom files for things like themes :/
Sneak peek of M3
Components that are Material 3 ready should opt-in to Material Design 3 with
useMaterial3
.https://api.flutter.dev/flutter/material/ThemeData/useMaterial3.html
Material 3 support in Flutter is currently in pretty early stages, but staying ahead of the curve on design can't hurt too much :)