-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Pull together all Flask-Admin theme configuration #2462
Pull together all Flask-Admin theme configuration #2462
Conversation
Will you plan to expect the new theming frameworks? Not just Bootstrap. Like adding Tailwind, Materialize etc? |
I don't necessarily expect them - but this would support them fairly easily and allow end users to provide whatever configuration they want for their template mode by subclassing TemplateMode with additional attributes. |
Would it be better if we create a seperate module for their understanding then? The usage would look like this: from flask_admin.theming import Bootstrap5Theme, TailwindTheme
admin = Admin(..., theme=TailwindTheme(**parameters)) |
Yes, that feels like a good shout 👌 |
I like how the things are going 🤓. I might have few ideas about this: First of all, I think the base class should not have a swatch attribute because future implementations (etc. Tabler #2444 or Tailwind) might not have that option. I will get back with more if/when I get chance to review 🧐. Great ideas 🚀. Also, this should be definetely in v2. |
The base class doesn't have a swatch attribute - just a folder 🙂 Tablet, Tailwind etc should inherit from the base 'Theme' |
Oh sorry, I was mistaken. I had my phone while looking at the change you made and ı probably didn't notice it 😅.
You are right 🧐. |
Currently, Flask-Admin themes can be changed through a combination of configuration modes: * Through Admin() arguments; Admin(template_mode='bootstrap2') * Through environment variables, eg FLASK_ADMIN_SWATCH='cerulean'. These two modes work together to decide the UI framework/version used, and then the colour/styling applied within that framework. This patch switches us over to a single `theme` configuration object passed to the Admin instance. This brings all of the configuration for a specific visual style into one place, and also means that now separate Admin() instances can contain all of their styling information in an isolated way. This should also make it easier for end users to provide their own Admin theme, as the theme is also exposed to all of the `render_template` calls under a `theme` variable.
Do we think Like this maybe: 09445e4 |
fix: #2423