Custom themes

[martpie]

Atm, the UI is not definitive, but once it'll be frozen, we'll be able to do something about it.

• [x] requires #87: Compile Sass on the fly
• [x] replace the native dark theme toggle by a select
• [ ] define where the user has to place those themes (.config/museeks/themes ?)
• [x] define how we scan these themes
• [ ] create a museeks-theme-builder with a doc on how to create custom themes

[YurySolovyov]

Are you sure we want this for 1.0? I consider this feature as pretty complex and difficult to support.

define how we scan these themes

Maybe like so:

.config/museeks/themes
  └─ <theme-directory>
   ├─ theme.json
   └─ theme

where theme dir contains required resources and theme.json defines metadata such as theme title and possibly other stuff.

One point IMO is missing:

• [ ] how do people discover and install themes ?

Should it be done manually or we need some kind of themes repo/storage/place?

[martpie]

Actually you're right, it's not really needed for 1.0.

About theme discovery, I have currently no idea. Maybe feature a few ones. Or make a repo listing them (like electron.atom.io).

[nalanj]

I really like that there are some strong opinions on appearance and overall UI - I'd be supportive of the app not having themes at all.

[martpie]

@commondream Do you mean only dark&light themes, only one theme, or only official themes ?

[YurySolovyov]

I'm kinda on both sides here.

One thing in favor of supporting themes is that some of the users might be a very talented ones, and can come up with a better themes that we do, so it would be a bad thing to miss this.

On the other hand, custom themes require building significant infra around them and it is easy to get things wrong.

[nalanj]

I could see providing light and dark if it's something you're missing for yourself.

Ultimately I think the CSS is so easy to tweak that anyone able to design could make their own themes without a theming system.

[YurySolovyov]

I don't really miss it, I just think there are a lot of creative people out there, and that we can borrow something from their designs if they can make something better then our current UI/UX, and this is really an endless process.

[martpie]

We can create a theme system/scan in the config directory without guaranting any support for outdated themes ect...

edit: in any case, this is definetly not an important feature as I consider the two built-in themes "ok".

[dkniffin]

I think this would be a pretty cool addition to the app. I'm picturing something like Atom's theme installer. But I agree this isn't a 1.0 kind of feature.

[YurySolovyov]

One possible idea would be to have same discovery mechanism as we have for music: scanning user-provided directories for themes.

Another interesting topic to consider:

• [ ] How do we fallback to default theme in case custom theme is broken but not in a way we can say for sure (just broken layout won't trigger any errors)? Maybe a CLI flag like museeks --reset or something ?

[martpie]

For those still interested, I am refactoring (rebuilding to be more precise) the app styles.

With the new system, themes should be quite easy to implement, runtime-applicable, and only with CSS variables.

[igorer88]

For those still interested, I am refactoring (rebuilding to be more precise) the app styles.

With the new system, themes should be quite easy to implement, runtime-applicable, and only with CSS variables.

Only with CSS variables? What about sass? @martpie

[martpie]

Sass was used before. CSS variables can be changed at runtime, Sass variables only at build time.

This means using Sass for themes is complex: itneeds to be compiled to CSS, stored on drive, it takes time and is not user-friendly.

With thre refactoring, the themes are just JSON files declaring CSS variables, which make them easy to write and parse, in exchange of the number of things that can be changed (which imo is a good thing, to keep Museeks consistent between themes)

[igorer88]

Didn't know that :+1: