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

adding css for script manager color interface to main styles? #382

Open
ChristianBirzer opened this issue Feb 7, 2022 · 2 comments
Open

Comments

@ChristianBirzer
Copy link

While learning how to use and write lua scripts for dt I was wondering what the color interface is and why it won't work at all until I read the source code and found issue #332.
Of course, the css for the color interface can be put in the custom css but I wonder if it would make sense to integrate it in the official themes to at least have a starting point for individual changes?
As I can see, color isn't a darktable thing as gray is way better for such an application. Thus, I'd propose a more muted green for active scripts, something like this.
grafik

Do you think it makes sense to prepare a PR for the dt themes with a little bit of color for that? Are there already any style guides for non-gray stuff?

@wpferguson
Copy link
Member

18 months ago (when I was adding the ability to style lua widgets) we had a big discussion about where to put the CSS and about using color in the UI. At that time we decided to put the CSS in the user.css file in the darktable user directory. As for color, we decided that it was OK to use color where it made sense, but not to use color just for the sake of using color.

The way I choose to colorize script_manager is as follows:

smcolor

This works better for me and my old eyes.

Perhaps we could write to the user.css file and then force it to be read, which would apply the css.

Or, we could perhaps have a css directory in the lua-scripts and then the theme could look at it and load on startup.

Part of the problem is that the themes are part of darktable and we only release twice a year. The lua-scripts aren't on a release schedule, so we could update anytime. A solution where we either force the load (write to the user.css) or check on startup (theme loads any css files from the lua-scripts) seems like a better solution than modifying the themes.

@ChristianBirzer
Copy link
Author

I like the idea that the lua scripts can bring their own theme. This makes it more flexible to react on changes in the scripts.
On the other hand, it would be nice if the lua-theme would be aware of the main theme. E.g. if the main theme is a dark one the green could be darker than for a light main theme.
Additionally it could be handy to have a "high contrast" setting? Or should/could this be done via the user.css by hand?
I mean, my main concern is to support the styles at all that the lua scripts use (because initially I was wondering why the color interface didn't do anything at all until I learned about that additional piece of css).

I could imagine that we extend dt to look for a lua/theme directory and add the .css from that directory (or let's postfix it with "..._lua.css") just like it adds the user.css. Doing so we could add one css for each main theme. I'm not sure how imports would work between them though.

This would require a modification to dt only once to get the lua theming running.

But, more questions arise:

  • How could we add a high contrast setting?
  • Shall each lua script bring its own piece of css? So that only active lua scripts will add styles to the theme while inactive wont. Than it will get a lot more complicated...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants