Getting Human & Human-Clearlooks back

Tips, Tricks and Tutorials Tried & Tested
#1

How to get traditional Human and Human-Clearlooks themes back into Ubuntu Mate 18.04

Now I am at Ubuntu Mate 18.04 and tweaking themes again. Here are notes on what has been done and how.

Install original Human theme:

# apt install human-theme humanity-icon-theme

You get gtk-2 Human, Human-Clearlooks themes and Humanity icon set.

Download https://github.com/GlassGhost/pwf python widget factory for gtk2 & 3 to compare original gtk2 version and your own tweaks to leverage difference.

Prepare basis
Copy /usr/share/themes/TraditionalOk theme folder into ~/.themes

Rename copied folder to <name> and cd into it.

Delete ~/.themes/<name>/metacity-1 folder.

Copy /usr/share/themes/human/metacity-1 folder into ~/.themes/<name> folder.

Edit ./metacity-1/metacity-theme-1.xml to substitute TraditionalOk name occurence with <name>.

Edit ~/.themes/<name>/index.theme

  • substitute TraditionalOk name occurances with
  • set IconTheme to 'Humanity'
  • set CursorTheme to 'default'

Migrate <source>, i.e. Human or Human-Clearlooks GTK2 settings
Open /usr/share/themes/<source>/gtk-2.0/gtkrs and ~/.themes/<name>/gtk-2.0/gtkrs and ~/.themes/<name>/gtk-3.0/settings.ini side by side

Copy 'gtk-color-scheme' color values from source gtkrc file to targets.

Open ./gtk-3.0/gtk.css

  • fill obvious color definitions in 'color scheme' section with gtk2 color values
  • replace 'core_color_a' value with of 'theme_selected_bg_color' value
  • replace 'core_color_b' value with of 'theme_bg_color' value

Open ./gtk-3.0/gtk-widgets.css, search for 'rgba' and alter rgb triplets by swapping 'r' and 'b' colors.

Open ./gtk-3.0/img directory and adjust colours in 'border-focused*.svg' files.

Optional tweaks (do not forget to change colors in all files mentioned above)

  • window background is too bright:
    theme_base_color #ffffff -> #EDE4DC

*selection bar color could be less bright
theme_selected_bg_color #8F5F4A -> #C79C89

  • scroll bar is too bright
    core_color_a #a4c2e8 -> #C79C89

  • I like rounded scrollbars...
    open ./gtk-3.0/gtk-widgets.css
    find 'scrollbar slider' around line #2370 and change parameter 'border-radius: 0;' -> 'border-radius: 20px;'

You can get revised Human & Human-Clearlooks themes here: https://www.mate-look.org/p/1309630/

Cheers!
ugnvs

3 Likes
#2

Just out of curiosity, what did you use for this? I'd kind of prefer not to have to install a monstrosity like GIMP just for something so trivial - but I will if I have to. :slight_smile:
(Of course, life would be better if the GNOME team had literally even just one graphics developer, because then we wouldn't need to deal with crap like this by hand. sigh. oh well...)

re: themes in general: I've also been preparing for 20.04 (which is when I'll move my real machines from 16.04) by restoring Clearlooks(-ish). One (to me) crucial thing in my git log that isn't in your post is:

f501c3ce76efe7169aae42803fb76b30cab85e33 Thu Sep 12 20:17:43 2019 [arQon] 
handle the hover color issues correctly, i.e. via a blend of bg/selectedbg rather than just saturating towards white

Basically, working with that methodology makes it possible to have "white on dark xyz" as the Selected pair, while also still working correctly for dark versions of the theme. It's not "required" at all for your specific theme, but it's fairly easily done and takes things one step closer to the restoration of user color choices becoming automatic aside from editing the core colors themselves.

#3

Disclaimer: newbie, not the original poster, but: SVG files are going to want Inkscape to modify them directly.
Also fortunately, SVG files are text markup based rather than bitmap! I'm currently trying to take a look at the Human(ity) icons etc in question myself, but if they use a standard set of colours in the SVGs in question, it should be possible to work out some sort of script/command to automatically replace one colour with another across the whole directory?

#4

if they use a standard set of colours in the SVGs in question

They do, sort of, though unfortunately the colours are unsuitable for this task - they need to be edited to something "good" (i.e. white) first so that they can then be modulated.

it should be possible to work out some sort of script/command to automatically replace one colour with another across the whole directory?

Exactly so. :slight_smile:

I was expecting to have to write the code for it myself, but I noticed that the 19.10 beta has added ImageMagick to the default apps - and that happens to actually be quite good at doing batch conversions on images, as long as what you want to do is simple enough. So that may end up simplifying things quite a lot.

#5

Ah, that's good to hear! I'm experimenting a bit with batch processing colours in icons/themes for myself, so that sounds useful. Hope it works for you!

#6

I use InkScape for vector and GIMP for pixel graphics.

#7

@ugnvs - Thanks.

After poking around a bit more, it looks like the SVGs will be trivial to fix.

The baked images (sigh...) for things like radio buttons are more of a problem, but I think it's doable: I'll experiment next weekend.

#8

To give a (realtively) simple example of how to fix the SVGs:

Open up border-focused.svg from TraditionalOk IN PLUMA. There are only 2 lines that matter, because there are only two colored elements to the image: line 93, which is the highlight; and line 102, the lowlight. Replace the color values (called "stroke", NOT the ones that say "color", because that would make too much sense :P) with ff0000 and c00000. (If you've ever done any color work, you'll recognise that as red).

The point of this stage is to create a color key to work with. We're using red specifically because that's where the Hue wheel starts. Ordinarily that would be a poor choice, but it'll help with some ImageMagick clunkiness later.

Unfortunately I'm going to have to pause here, as it turns out the ImageMagick in 19.10 is buggy and can't actually output valid SVG. (And I need to go to bed!). Hopefully the concept is clear at least.

TBH, I would STRONGLY consider using text tools rather than IM to change the SVGs even if IM actually worked, because there are a LOT of stages involved in it (e.g. restoring the G+B layer to white, stuff like that). In fact, I'd probably alter the base SVG further and explicitly make the white layer G-only, to reduce the amount of hackery that will be needed to generate the composite, or just split it into two distinct layers the way anyone competent would have done in the first place. The only "reason" to use IM for the SVGs is because we'll be doing the same steps with the PNGs later, but those too would probably be better split into layers by hand first.

@ugnvs - Sorry for practically hijacking your thread at this point! Hopefully this is interesting enough for you to forgive me. :slight_smile: