Color options

[TiZ-HugLife]

This pull request adds some color options in the form of new features only implemented in the color change script, Gtk2 and Gtk3.18. I don't have confidence in editing Gtk3.20 when I'm not currently using an OS that uses it, and I haven't yet attempted to adapt the GUI to it. Honestly, haven't even looked at the GUI code yet, haha. I'm okay with Python, I might append to this pull request later with those changes so that's one less thing you have to do.

This PR introduces the following specifically:

1. Tab color modes. Oomox: bg as active, shade as inactive, Numix: base as active, bg as inactive, and custom: define active and inactive manually.
2. Border color modes. Oomox: mix bg and fg, Shade: shade the widget in question by specified amount (0.75 by default), ShadeBG: all border color widgets based on shade of BG, and custom: define all of them manually. Also, by specifically defining this in script rather than in gtkrc or CSS, we can also apply them to the assets, and we do so.
3. Tooltip colors. I haven't been affected by this deficiency personally since I have an override that makes it always white on black, but right now, it seems to be FG on BG. Tooltips are supposed to stand out from the content they describe, and that coloring defeats that purpose. I made a judgment call here; default tooltip colors are MENU_FG on MENU_BG * 0.5. You can set this manually too if you want.
4. Border color implementation in 3.18. I don't know what all is actually missing from 3.18, but this omission was particularly glaring so I fixed it.

Also I sneaked in a new contrib color scheme, thanks for keeping my old one around. I didn't mean to, but I'm glad you liked it enough to keep it. :)

Please feel free to make any changes you deem necessary.

[actionless]

thanks! very big thing to take a look into so i will take a look on code and will do some testing with different color combinations on the weekend

but i already like the idea since some similar configuration options were demanded for quite a long

in the meantime i will ask you to squash some of the commits (PRs shouldn't have commits with fixes to code introduced in the same PR)

P.S. i don't mind colorscheme contributions even from people who don't ship any code together with it :)

[actionless]

also in shade.sh you're not controlling minimum and maximum so output value could get out of range between 000000 and ffffff

see how that's implemented in darker.sh

just as a sidenote: i think it would be better soon to reimplement all those bash scripts as python code, to avoid duplication between change_color.sh and preview code in python GUI

[actionless]

so after you'll do two things mentioned above, i'll adopt it to a new branch, there i will port it to gtk 3.20 theme and implement preview

regarding gui configuration -- options can be added here:
https://github.com/actionless/oomox/blob/master/oomox_gui/theme_model.py

[actionless]

do you have any plans to continue working on it or i can adopt it to continue the work?

[TiZ-HugLife]

Hey, I'm really sorry I've delayed work on this. I got swept up in a bunch of stuff recently and have been kind of swamped but should be good to finish work on this after this weekend.

[actionless]

take your time, i was just checking if you are going to return back to this

[actionless]

now theme is located in this repository:
https://github.com/actionless/oomox-gtk-theme

[actionless]

also i've dumped your branch on the new repo:
https://github.com/actionless/oomox-gtk-theme/compare/master...actionless:border_options?expand=1

[actionless]

@smurphos what do you think about reviving this?

[smurphos]

It looks interesting. I generally think more options for configuration are a good thing but then we need to consider the added complexity to end users.

A couple of things have bothered me about Oomox GUI as a user which could also be addressed if we do look at adding additional options for the Oomox theme.

1. I think it's quite confusing for the end-user that Terminal colors are reused in the GTK theme without it being clear in the GUI that it happens or which Terminal colors are relevant for the GTK theme. I think those colors should be separately defined and available to be set in the GUI (warning, info, error, link etc).

2. The scroll down design of the GUI can make it hard review settings across a theme - have you considered a tabbed design? Something like tab 1 with 'main' theme color choices, tab 2 with secondary theme color choices (including the border options talked about here), tab 3 with icons, terminal etc.

3. Again if we expand the number of configuration available to users I think a great feature would be 'Suggest settings/colors' button. E.g. user makes their 'main' color choices and presses the button to prepopulate the secondary colors/settings with sensible suggestions derived from the user's initial choices. It would an interesting exercise to code that. Long-term being able to suggest settings/colors for different use cases would be good - e.g. suggest settings for a compact theme, suggest settings for a high contrast them, color-blind friendly theme, 'fun' vs 'soothing'....

[actionless]

1. after implementing pt. 2 that will be fine.

2. i was considering either tabs or expandable tree (like theme presets are grouped by top-level directory now), please create a separate ticket if you want elaborate more on this

3. i was also thinking of similar. so far i've came up with the following concept (feel free to propose different) -- to each theme type to add the option which only terminal theme have now -- to choose between Auto palette, Basic and Manual (and/or more). as well i think that worth having separate issue to discuss that.

to summarize - i have a similar opinion on the topics but 2 and 3 require some discussion before implementing

4. Possible collaboration #130 (comment)
   we could also have somewhere in the beginning just a base-16-like color palette and next for each theme type (gtk, icons, terminal, spotify, whatever else) to choose between Auto, Basic, Manual, etc like it's now done for terminal
   . that almost the same idea as in pt. 3 but seems to be more straight-forward