Allow themes to be customized

[mintystark]

I am wondering if there is any word on allowing themes to be customized in the same since as Applets. I am thinking that in the Theme Manager where you can see the themes and "Apply theme" that when the theme is selected there is a "Customize Theme". Nothing fancy, just a simple settings popup like the Applets do. Same settings fields like text, checkbox, select, etc. With the only difference of having a color picker. Then an Apply button which would reload the theme.

The easiest thing would then be to have the values in the theme css file.
Something like $setting['setting_name'].

So like:

main-background {

 background-color: $setting['mb_background_color'];

}

We would also need to be able to set defaults just like the Applets Settings have.

I am thinking of making an Applet that would do such a thing for specific themes, but don't want to waist my time if you in the works of having this.

Thanks

[mtwebster]

This is not really possible right now, as themes don't currently support any sort of variables or way of injecting changes into the themes like this. Right now each color must be explicitly spelled out every time it's used. Support for this is planned - and some coding is done - but there's no deadline or anything for it. It's relatively complicated to implement.

[ghost]

@mtwebster Ohh, do you have an interesting idea about how can be do that. My idea about that was incomplete because in css you can do the same thing in differents ways.

I thinking in to have a main css with more priority that the current theme, this css, could be active only in the case that user decide modify some properties, and override the default css of theme(set_style_class)... The problem will be that in the default theme you can set style to some childs, for example, and you can lost this, or you can set a two thing in the same atribute and the user only want to modify one. Like for example color and border, and user only want modify the color, not the borders.

For this problem i was thinking to use the css forcing atribute that it's comptible with css 3, but not with cinnamon right now. See(!importan): http://webdesign.about.com/od/css/f/blcssfaqimportn.htm

Then do not override the theme. Only forced Cinnamon to set the new user attribute value with more priority. Then Cinnamon need create an alternative theme(a new css file) to set this like add_style_class do, and not like set_style_class, to avoid override the rest of atributes. The problem with this can be the implementation of forcing attribute(!importan), but like css 3 allow this, sure that can be implemented...

The problem with this will be that forcing a color value(in string format), can not be apply correctly if for example: The background for color will be an image in the theme and not a color implemented with color value in string format.

Your solution to have variables inside the css it's interesting, but have two problem:

1- All cinnamon themes need to be update to use variables and not constant values.
2- You lost the posibility of implement a thing with an images if the variable requiere a color string for example.

Will be interesting apply compiler techniques to a css with some variables, to generate a just in time css static, to be apply. Also generate a GUI base on the attributes that the author of theme decided to implement using a variable.

[koldbyte]

@lestcape @mtwebster take a look at LESS. (http://lesscss.org/) Less allows variables and some programming techniques.
A theme may be developed in LESS format and when a user applies the theme, Cinnamon can run the LESS 'compiler' to convert it into css files and use them as it does now.
Moreover, the theme system can allow a tag for now to mark a theme as "less" format and process accordingly.
I believe using an existing and popular system will be good.

[mtwebster]

I'll have a look, thanks. I'll have to see if it'll work for us, I don't think Cinnamon uses a standard css implementation (but that may not matter).

[ghost]

@koldbyte this appear to be excelent... and also appear that works like the idea of @mintystark and @mtwebster.

Thanks.

[mintystark]

It doesn't have to be as literal as I mentioned. The Apply button could just be a function that opens the css file and does a string and Replace. In order to keep the location of the String and Replace for further Edits we could wrap the value with comments.
Ex
.main-background {
background-color: /* $MAIN_BACKGROUND /#FF0000/ END $MAIN_BACKGROUND */;
}

I just tried this and the comments don't seem to interfere with the css. It loads fine.

The Main point is you can put more work on the Theme creators if needed.
This is essentially my idea for an Applet that would just search through the 'cinnamon.css' file and search for any variables then allow the user to place in the values and upon Save it would open the file replace the values and then re-load the theme.

I don't think that this would be too difficult although I have not done any file editing with an applet.
Also I think having an Applet on your Panel is not the best place for it. That is why I think it should be in the Theme Panel.

It would be even better if the theme creator could define eveything in the css file so they wouldn't need to manage a settings file. Just come up with the Format and we will follow.

Ex.
.main-background {
background-color: /* [name=Main Background Color,type=color_picker,default=#FF0000] /#FF0000/ [end] /;
background-image: url(/ [name=Main Background Image,type=file,default=/usr/share/icons/default.png] //usr/share/icons/default.png/ [end] */;
}

[ghost]

@mintystark: Like i see the idea it's good, but there are several question about this, that need to be defined first. Just for me there are two general ways. One can be that author of theme can define the attribute to be configure(not cinnamon as an standar), and another can be with static attributes(cinnamon defined this attributes). The first option will be more general, but more complex to understand for user, because they can not have the same properties to modify always. The second way, force to author of themes to be compatible with this way, otherwise theme can not be apply, and css could not be flexible.

Just one example to see how complex could be:
You can define borders like an images. See for example: border-image in Zukitwo-Cinnamon theme. So, you can set background color like you want, and this color can not be apply. This occurs because the image that you use for borders, also define the background, so do not allow to see the color.

Another more complex example could be the use of first-child (http://www.w3schools.com/cssref/sel_firstchild.asp) or last-child. Using this attribute you can set an style using the parent of the element and cause a problem to set your configuration.

There are many examples like this, so the problem it's really complex and you need to have a complete specification of css to see how you can set an alternative style, and decide what do you want to do with this alternative way, to not cause a bad behavior.

[collinss]

I wonder how hard it would be to set it up to use the settings api for applets, desklets, and extensions (or something similar). Such an implementation could have certain global properties defined in the css that could be used throughout the stylesheet. This is already supported in certain implementations of css (GTK 3 for example, though not currently in Cinnamon themes). These global colors, images, etc. could then be pulled from the settings api, or be defined explicitly in the stylesheet.

One advantage to doing it this way, is that it would fit in well with what we already have. Another advantage to doing this is that applet, desklet, and extension developers could potentially have styles to pull from in their own stylesheets to make their spices blend in more with the current theme.

[mtwebster]

@collinss That's pretty much exactly where I want to end up with this.

First though, we need to implement a pre-processor to take these 'variables' (wherever they end up coming from - the theme itself, some configuration, or either (user-customizable)) - and have it process the theme and come out on the other end with a fully expanded style sheet. Our preprocessor also has to be recursive, so I can, for instance, nest variables inside of each other.

Some of this may or may not be helped by that LESS program, but we have to weigh is it easier in the long run to do it ourselves (so we can build-in the plumbing for this?) or to use this 3rd party program to handle some of it for us. Currently I'm leaning towards doing it ourselves.

[mintystark]

In the long run it would be nice to just have a another file. I prefer scss
settings.scss.

At the Top you will define your variables.
$main_background_color = #FF000;
$main_background_image = /usr/share/icons/default.png;

Then below you would have all your css

Ex.
#main-background {
background-color: $main_background_color;
}

On Apply/Save it would just do a Regex replace on the Variables Values.
Then it would compile settings.scss to settings.css
settings.css would be loaded after cinnamon.css

Of course this would require compass or another scss compiler to be installed.
That is the only downside that I see.

[ghost]

@mtwebster The problem with doing something yourself is always time. Using the time that we have, something good can be done for resolve all current problems, or maybe just some of them. There are some things that will not see until it is done. If you use a tool that takes some time and is good, sure this tool include many things. It's likely to have things that you not needed for your task. I am of the view that it is preferable to use something that is already proven, perhaps not directly, simply clone and follow developing one. Begin to do what is already done, I think it is going to represent a lot lost time.

@collinss i think that all agree with you, but I still have the idea of ​​who should define these mechanisms, is an specialist web design and not a great programmer, because of the number of inconsistencies that could be generated. Another example, this already high level:

Cinnamon defined a color for the panels, this will be the same as for the desklets background?

Yes: then a theme with a different color on the panel and the background of the desklets not be allowed.

No: then if the user change the background color of the panel it's possible that will want to do the same with the bottom of the desklet. And I wonder if the deklets also will have this value in the configuration.

How many values ​​will then be possible to configure? Which values?
How far will lose flexibility the cinnamon theme if this will be added?
It could be that the user changes a value of a property and this change is not seen on cinnamon because other property is limiting, without can concidere this, as a Cinnamon error?

[mtwebster]

I would prefer to do it ourselves because I could spend just as much time trying to adapt something else to our needs.

We don't want to get out of hand with this, either. If this is implemented in some way early enough in the development cycle, we can get feedback from theme designers as to what should be included.

I also don't want this too complicated. Basically, the bulletpoints for what I was originally (this was 6+ months ago) thinking are:

• Existing themes will work as-is, unchanged, but will not support customization
• We will predefine certain accepted variable names, supported themes can use some or all of them, and add their own if they want (which may not necessarily be configurable by the user - they could just extra nuances that theme developer wants to use)
• A customisable theme will have some sort of header section, where these variables are defined.
• Throughout the theme, these variables can replace all or portions of the CSS definitions.

At run-time, any time a theme is loaded, the .css file is read:

• If there are no variable definitions (old theme,) it just works.
• If there are variables, they are recursively inserted/expanded throughout the theme until full expansion is achieved.
• The resulting css is then loaded as Cinnamon's theme.
• One can go into Cinnamon Settings->Themes, click to configure the active theme (only the active theme), and it will list the variables used, and allow them to be changed. User clicks 'apply', the theme is recomputed with these new values injected into the preprocessor.

Extra thoughts:

• If a user likes his/her current theme, and has customized it, they can save the active css to a file
• If a user just has certain standard variable settings, they can save/restore those

I see the biggest challenge as how do you create a UI to customize this stuff, when it's not just a color you're picking - it could be a shade of a color, with a gradient, etc... Just a blank entry field? So maybe some base color specifications for a theme (which an inexperienced user can use to just change colors with a picker), followed by more advanced fields where those colors are mixed with gradients, etc.. to make a complex shade.

@lestcape Yes development time is always a premium, but for what it's worth, I've been wanting to do this since before 2.0, and it was one of the few things I really wanted to get done for 2.4.

[ghost]

@mtwebster this is amazing, you have a mature idea about what you want to do and you solve several things of my questions. Really....
"I see the biggest challenge as how do you create a UI to customize this stuff":
One idea could be that user select primary attributes like "color", "images", "size".... Then user need to select the places where this value can be set, if it's in "shadow", "shadow gradient-start", "shadow gradient-and", "background"... So, the attribute to modify could be added dynamically, based on user preferences and if in the current theme can support this action(base on the internal variables that could be defined by author or not). The problem will be if this mechanism could be difficult to users. But it's just a primary idea...

Thanks for losing your time explaining your idea.

[mintystark]

I think we are all in agreement. Just need to find the right process.

One thing I want to say is I don't think that it needs to allow for complex settings like box-shadow, gradient, etc. Not at first anyways. Anyone who really wants to configure that and knows about those settings will most likely know how to edit the css file themselves. This should be made for users who just want to configure their theme a little to match their Style. Many Times I just want to change the main color used to match my OS (Mint=green, Ubuntu=Orange, Fedora=Blue, Etc). So instead of someone creating X Amount of themes, they just create one.

One issue I have with Cinnamon Themes is there are a few creators that are creating too many just to change one color. Sure it is their right and I am glad that they are participating so much, but it is filling the Theme Repository too fast and it is making Updating the Theme Cache take way too long.

[mtwebster]

I agree... less themes, maybe let them provide one style sheet, and multiple QuickSets(patent pending!) or something to vary their colors.

[ghost]

@mtwebster i don't know what really do jdownloader, but on version 1 the update occurs several time slower, than on version 2. So appear that they compress(in version 2) the cache in the server and then download only one file faster or some thing similar. Can not be a procedure to do a more faster update of spice? Also can not be do an automatically update when the cpu is in idle? Also cinnamon can come with the current state of spice inside, and this can reduce the first update.

@mintystark like i say i agree again with you, but i think that process need to be done general, then you can deside about what arguments you really want to change from users... for example could be added an if staement to the css and access to system time and you can use for example a theme that can change a color depending of the hour. Cloud also be implemented events to evaluete again the theme with a timer, coud also css be conected with cjs instead on have another programing languages and do more complicate stuff...

[collinss]

For what it's worth, what I was envisioning for the UI would be to use a settings file (like the settings-shema.json file for applets and desklets), where certain widget types (eg, color picker, slider, spinbutton, possibly file entry for background images, and combobox for @mtwebster's so-called QuickSets, etc.) can be specified by the theme developer, and then the values are inserted into the theme.

[mintystark]

That was my original though as well.
Use something that already exists and that we are familiar with.

[ghost]

It's just out of normal and could be a problem, that box pointer do not recognize the actor.style, just because the style is reading for the actor themenode and not for actor.style. In some context this could be limited to the applets to change appearance, like the desklets can be done as well.

There are a duplicate call in box pointer. Also duplicate the declaration(not produce any problem)

_reposition: function(sourceActor, alignment) {
...
        let themeNode = this.actor.get_theme_node();
        let borderWidth = themeNode.get_length('-arrow-border-width');
        let arrowBase = themeNode.get_length('-arrow-base');
        let borderRadius = themeNode.get_length('-arrow-border-radius');
        let margin = (4 * borderRadius + borderWidth + arrowBase);
        let halfMargin = margin / 2;

        let themeNode = this.actor.get_theme_node();
...

[coryhilliard]

Is there a voting system in place for this feature? I find this missing feature is THEE number one missing feature since the demise of Gnome 2. I have built my own theme, but I would love to have just a simple pointy and clicky (as most users of operating systems would too). Just because I can code CSS, doesn't mean it's fun all the time.

[yro84]

well, where can I see a proper tutorial about how to customize the default cinnamon theme? I just want it to have the blue line above the name of the program window on the main panel, I just want this panel to be fully black (real black) and I just want to change the main selection colour to pick orange or something similar to a darker blue. Just simple things like that. Where can I get the how to? Atleast where can I have informations about these things I wanna change on the main theme?

[cruftytheclown]

I would like to be able to control the transparency of individual panels.

Then I would use a normal non-transparent panel at the bottom of my screen, and a fully transparent panel at the top of the screen where I would put notifier applets in the top right corner.

[germanfr]

@cruftytheclown this may be what you need: https://cinnamon-spices.linuxmint.com/extensions/view/42. The individual transparency is not a feature yet though.

[rustedwolf]

If a color custom prime color selection would be implemented, that would be a very big plus for cinnamon. Then again it there would be no need for large preset list, like it was in Mint-X. Just select style > then select a color from preset or custom color.
Right now Mint-Y theme (as I look in my settings) has only green color theme, so they won't match up with Mint-X icon other than green color presets...

[JosephMcc]

I'm going to close this. This has been discussed internally multiple times and there is no nice and easy way to implement this and make it work nicely and up to the standards users probably expect.

[Mario-paul]

I wasn't sure if I should post here or open a new issue but since it is the same thing I'll just post here. If it is wrong please let me know and I'll post a new one!

So I am creating/modifying a new set of themes, and it's come to my attention that the values for many elements are hard-coded on the CSS. This is incredibly inefficient and explains why you need separate themes to simply change the accent color of the different Mint-Y themes.

Within the last few years CSS variables have become a thing, and are supported by all major browsers. Cinnamon being a sleek, modern desktop environment, I tried to implement variables in order to easily modify elements on the fly, but it seems to break the rest of the CSS. I'm doing it just like on regular modern CSS, like so:

  :root {
     --test123: rgba(243, 0, 0, 0.59);     
  }

.panel-top, .panel-bottom, .panel-left, .panel-right {
  color: #ffffff;
  border: none;
  background-color: var(--test123);
  font-size: 1em;
  padding: 0px; }

is this something the Linux Mint devs plan to ever add?

[JosephMcc]

There are no intentions to support this currently. For many of our own themes we currently use sass which gives you very similar functionality.