Is there a way to access subThemesData from context

[Flucadetena]

I would like to set the border radius of a container based on the general border radius i have for everything. So extracting it from a button or any other component that has its borderRadius already set by the theme.

But I can find any way to access it from the Theme.of(context). As on my set theme i've modified lots of border radius in the "subThemesData", Is there a way to access does properties?

Thanks again for all the time and help given.

[rydmike]

Hi again! 👍🏻 😃

FlexColorScheme does not in its current version create an inherited widget that you can use to access any of its properties with in the widget tree. Perhaps this is something that could be useful in a future version.

However, since all the values it was assigned, end up somewhere in your theme, you can extract the values from Theme.of(context). Getting access to the border radius in a component theme is actually something I pondered about earlier too, and even use myself in the Themes Playground app.

One example is the cards around controls. You might have noticed that they sometimes have a border:

but when the color diff due to theme setting changes, so it has different color diff from background, the border is removed to create a no outlined design when the outline is not needed in the theme to separate the container:

It also handles the themed border radius changes.

The HeaderCard widget I made for this in the Playground actually does not know anything about the input settings used FlexColorScheme, it just reads all it needs from the theme, copies existing sub theme, reads the border shape from the theme, copies it with the BorderSide applied when needed.

It also does this without any assumption or knowledge of if there even is a ShapeBorder in the Card sub theme, and uses M2 and M3 defaults radius defaults depending on M;2/M3 mode, to add one with a BorderSide when there is no ShapeBorder at all, since CardTheme prop is null by default.

You can find the example of this here:
https://github.com/rydmike/flex_color_scheme/blob/master/example/lib/shared/widgets/universal/header_card.dart

(I see I need to fix some comments typos for it my dev branch version, never mind that)

At this point in the code:

flex_color_scheme/example/lib/shared/widgets/universal/header_card.dart

Line 151 in 2a9b8ec

shapeBorder = shapeBorder.copyWith(

we are in situation where we know that, we have a RoundedRectangleBorder in the theme.cardTheme.shape and we could as next step access its borderRadius property and if it is not null read its BorderRadius. You have to unwind all the potentially null nested classes, null check them and use is of assumed class checks, before you can get access to its properties and read them, but totally doable.

In your case, if you always know you will have a sub-theme applied with a border radius, reading it is a bit simpler, since you can make assumption that there is a RoundedRectangleBorder in the card theme and that is not null. In the Themes Playground app, users can dynamically change everything, like even not use FCS at all and switch M2 and M3 mode without using FCS, so I cannot make any such assumptions.

There is also the super simple way, in your case in your FlexThemeData:

theme: FlexThemeData.light(
  scheme: FlexScheme.materialBaseline,
  surfaceMode: FlexSurfaceMode.highScaffoldLowSurface,
  blendLevel: 13,
  subThemesData: const FlexSubThemesData(
    defaultRadius: 11.0,  // <- Why not make this a const def and use it where needed in your app?
  :

The borderRadius you define for your FlexColorScheme, or any other of its props, are just const literal numbers or const classes, make it a const in a const config file, use that value for the defaultRadius and anywhere else in your app where you need the same value.

If it is value that the user can change dynamically, then use a controller and ChangeNotifier, or a ValueListenable, or if using Riverpod e.g. a StateProvider that you can access anywhere in your app to use whatever its current value is set to, both in your theme config and deeper in your app.

Still if you are not changing its value other than at compile time, just make a const value for it that you use wherever needed.

Some of topic tangents

For going deep into dynamic theming with FCS + Riverpod and persisted configurable theme settings with a swappable persistence layer, this example has you covered:

https://github.com/rydmike/theme_demo

It is fairly advanced though, doing things like dynamically swapping the theme persistence implementation in the running app, is probably not something a normal app needs to do, but the other parts with using Riverpod and persisting theme settings with Hive or SharedPrefs might be of interest.

Of course the Themes Playground app does something very similar, but without fancy Riverpod, it just uses a single AnimatedBuilder + ChangeNotifer based controller that it it passes around to wherever it is needed.

I did it like this, since originally Themes Playground was just small simple example 5, not much bigger than example 4 still is in the repo, but it kind of grew out of control 😄

The example apps and thus Themes Playground were also intended to examples of using the Flutter skeleton architecture, that you get with:

flutter create -t skeleton my_app    

I originally wanted to demo it as light weight alternative, which I think Themes Playground kind of proves, but it has imo grown out of its applicabile scale at this point. Everything still works fine, but it would be more easy efficient with Riverpod.

The Themes Playground app, uses FlexColorScheme package to dynamically theme itself, write the config code as you change its theme, for the dynamically FCS created theme you see. Plus in the yet to be released V7 version, it also applies that theme to a few demo mock apps that one can use to test and see what the theme looks like in a selected mock device using the same theme.

Yes the inception is getting pretty deep, lol

Some V7 dev.3 tweet teasers:

https://twitter.com/RydMike/status/1625183551397167104

https://twitter.com/RydMike/status/1623411629097381895

https://twitter.com/RydMike/status/1623840383603023872

https://twitter.com/RydMike/status/1623640406905835522

/Mike

[Flucadetena]

How could I have not thought of using a const. What a dumb me.

At least a learned a lot!! with your answer and will explore all other options and code you shared to learn more. I can't thank you enough and learn how to exploit more this amazing package you have created.

I can definitly see it has grown a lot the playground, but gotta say is the best thing out there, by a mile.

Hopefully I'll be able to learn more how it works and help in the development.

Thanks again for everything Mike, looking forward for version 7.