A complete overhaul of the asset creation and build process

[ccprog]

I'll be the first to say that this pull request is an impertinence. It aims to make future design processes easier to manage, but accomplishes this by exchanging literally every file that has to do with the grafical assets.

The work I have done does not change any design aspect of the theme, but only concerns the technical infrastructure.

Currently, there are partial processes to produce asset files from sprite-like overview SVG files. But these files are in a disorderly state (from a technical standpoint) and if you want to change something, the best you can do is a search-and replace in a text editor to exchange one color for another.

While it is not in widespread use for vector grafics, I think the principle of division of concerns that is well established for web design would be a clear benefit for structured groups of grafical elements like icon sets and the elements of a desktop theme.

Therefore I introduce stylesheets as a means to discern between the structural descriptions of elements and their coloring. (While the SVG format defines a lot more attributes as "style", only colors and opacities lend themself well to a succinct distinction.) Furtheron, at least partially, the definition of grafical primitives and paths are done in a seperate part of the file to provide them for reuse in multiple elements - think a checkmark, or the circle that defines the circumference of a radio button.

This comes together in a workflow like this:

• Draw the primitive components for the grafical assets, but void them of any style definitions (here: color and opacity)
• Group clones (<use> elements) of these components together to form the individual assets
• Group all assets and their components after the logic of their use, and appoint classes to make identification of related parts possible
• Write a stylesheet (using Sass) to define colors and opacities for every component

I have redrawn the existing GTK overview files and introduced new ones for the Cinnamon and XFWM parts. (There is even one for the Metacity part, but that has admittedly only a very minor benefit.)

For the next part, I have written a node.js tool svg-icon-toolbox that can

• compile the Sass stylesheets to css and inject them into the SVG file,
• distribute the styles from the sheet to direct style attributes of the respective elements,
• export the individual asset elements to separate files, either in PNG or SVG format.

This last part may look like what the various render-assets.sh scripts do, but it is much faster, because of the asynchronous execution and especially the use of the inkscape --shell command.

Finally, it seemed to me that introducing yet another tool into the build workflow is not really beneficial. So I bundled everything together with Grunt, including the compilation of the main CSS files and the copying of the files to the theme folders.

The changes in the workflow drop dependencies to Ruby Sass and Python, and add dependencies to nodejs with a minimum version of 4.0, the ImageMagick convert command and libsass. Inkscape and optipng remain needed.

The end result of my efforts is a project with several hundred changed files. I hope I have done a few things to explain what has happened why:

1. All asset overview files have been redrawn, and several have been added. In the README.md files for every subdirectory I have described the class structure of these files, which SCSS files belong to them, and given hints how to edit.
2. As an inevitable consequence, all individual asset files have changed. A pixel-perfect identity between files is an almost futile task. Instead, I try to document the amount and relevance of changes.
   Firstly, only the asset files in the src/ tree have been exchanged for now. Their counterparts in the usr/share/themes/ tree are yet untouched to facilitate their comparison.
   Secondly, there is a commit for every theme section that exchanges the asset files. If you look at these commits on github, you will find detailed analyses of the changes in the commit comment section:
   • Cinnamon: https://github.com/ccprog/mint-y-theme/commit/0177c98e3c1230cefea6c831066c16824f765428
   • GTK 2: https://github.com/ccprog/mint-y-theme/commit/5963bd2952a200a4fad20f46a90c601839db56e8
   • GTK 3: https://github.com/ccprog/mint-y-theme/commit/5ac1c1ad707df7163ebe7854ce40e62a3e7f13fe
   • XFWM4: https://github.com/ccprog/mint-y-theme/commit/e8e8879b10a621df980f7729c8e0635b83d03cf6
3. Exchanging Ruby Sass for libsass has the unfortunate consequence that also the main CSS files change. Most of these changes are only formatting related, but it seems that Ruby Sass has a few optimization mechanisms that libsass has not. If you look at these two gists:
   • https://gist.github.com/ccprog/83aa9a510bdd2c74608149fc2d0144bf
   • https://gist.github.com/ccprog/b823a9d5356e9552533406b0e5c333af
     you will find the slimmed-down test cases of the differences. In short, in some cases Ruby Sass deletes selectors when it finds that they select a subset of another selector in the list for the same declaration.
4. Looking at and comparing all the assets again and again meant that I have found some inconsistencies and errors that seem to have evaded spotting until now:
   • GTK 2 assets/toolbar.png differs between the source and distribution folder.
   • XFWM4 has a menu-prelight.xpm for the dark variant, but not for the light.
   • under usr/share/themes/Mint-Y-Dark/cinnamon/ are a few stray folders (menu, misc and panel) that seem to have got there by a faulty copy action.
   • usr/share/themes/Mint-Y/xfwm4/ has three extra files title-1-active-shaded, top-left-active-shaded and top-right-active-shaded I don't know what to make of.
   • https://github.com/ccprog/mint-y-theme/commit/65c468e032f19725cc97c10f2f2c8a92bde94c17 is a bugfix that would be needed independently of this request.

[JosephMcc]

Ok, so I have to admit I'm not familiar with some of the tools and things that you are using here. For me personally to be interested in this I would need to know that there is some real benefit to it. So my first question would be, what does all of this add that benefits us now or moving forward?

[ccprog]

The main motive behind this is making the process of changing assets more transparent.

Practically speaking: I wanted to have a variant of the theme with aqua coloring. What I needed to do was go through 40 asset files in cinnamon to find out what was mint green and changing it. For GTK 2, the only thing that was practical was a search-and-replace with a text editor and hoping that there were no color variants that I was overlooking.

You recently redid the XFWM assets (a0344c6b263bdf8dcdf64010a629fe7a82547931). I don't know what process you used, but now you could do that by changing src/xfwm4/sass/_assets-variant.scss. All colors used for the close icons, for example, are listed in lines 21-29 of that file. By the way, was it intentional that the light hide-active icon has a minus sign that is a tad darker (#909090 -> #808080) than the other -active icons?

With the new process, the SCSS files provide a central point and a understandable language for describing structures and changing colors. Deriving all assets from a single style ruleset prevents overlooking some cases if you want to propagate a global change.

Secondarily, the overhaul of the SVG files themselves makes them clearer. I don't know if you are familiar with the Inkscape XML editor, but normally looking up the color definition of an object should be a case of clicking on it and reading the relevant attribute. Wth the current files, it took me up to 30 seconds to sift through convoluted structures and non-applicable attributes for a single information.

Thirdly, the render-assets.sh scripts are using the Inkscape PNG export functions in a very inefficient way. They can be speeded up at least by factor 5. (Most of this improvement can be also achieved with a changed bash script.)

[JosephMcc]

Sorry for taking so long to respond. I know you put a significant amount of work into this.

I have some reservations about it though. It adds a lot of complexity that needs to be maintained just to make creating color variations easier. Creating a new color variation is a one time thing and not something we do on a regular basis. As I stated above, I don't even currently know how some of the stuff you are using works. That means I would need to learn it just to maintain it. That on it's own isn't a big deal but leads to one of the other reasons I'm not sure about this.

We don't receive a lot of help in terms of PR's and stuff with the Mint themes in general. I think even the addition of using sass in this theme puts some people off because they don't know it. I feel like having all of this would make that even worse. We see some of the same in our code repos. We get a lot of help with python or js based stuff but much less with the C based code. I intentionally removed some node.js and gulp stuff from the original arc theme when we forked it for Mint-Y.

[ccprog]

Considering I expected a plain "you're nuts" as a reaction, you are pretty nice in your answer :)

Just to understand your point: would you consider using plain CSS instead of Sass being less of a hurdle? Or is the combination of SVG with style sheets just too weird?

If you are interested in using some of the stuff I did and leave others out, tell me. The way the commits are organised it should be easy to stitch another branch together.

Finally, as I said, the render-assets.sh scripts can be much more efficient. Here is the variant for GTK3 - feel free to use it. (The point is that the current script starts a new instance of Inkscape for every exported file, while it could use the CLI shell and render all from the same instance.)

[JosephMcc]

I'm going to close this since it isn't really a direction we want to go.

Feel free to open a PR for the improved render assets script if you like. If the end result is the same as we get now and its more efficient, that's always good :)