* Improve GTK+3 theme loading
- Merge geany-3.0.css into geany.css
- Load geany-3.20.css to override if runtime version dictates
- Load geany.css from app->configdir if it exists.
* Add initial documentation for GTK+ CSS theming
* Add geany.css file to the `Tools->Configuration Files` menu
Also mark such config files as changed if they don't already exist to
force the user to save or discard any newly created config files.
* Allow customizing message window using GTK+ themes
* Improve GTK+3 CSS docs a bit
State which classes are meant to be overridden by themes.
* Go back to conditionally loading geany-3.0.css
It can't be merged into geany.css since GTK+ CSS parser doesn't ignore
invalid properties when prefixed with vendor extension (ie. -Gtk).
* Don't mark unedited config files as changed
They probably should be marked as changed since they don't exist on
disk yet, but for the time being leave it how it was.
* Fix misuse of CSS ID vs class in manual
* Minor colour value tweaks
Based on feedback from @b4n
Adwaita 3.20 on GTK2 uses the pixmap engine to set a background image
on all states of all GtkEntries. Earlier versions did the same but
with a transparent background, thus not hiding our background color.
Fixes#1135, fixes#1101.
Right now users are confused when various VTE actions don't work because
there's no indication that the terminal is in the non-clean state.
Visualise "modified" terminal in the same way as modified document - by
a red label in the tab so it's clearer when terminal isn't clean.
Avoid quick red flashes when pressing enter by delaying the color change
a bit.
We have a custom RC file defining various styles we need, and we want
the user to be able to override them (e.g. if they want -- or need --
other colors). Fair enough, one would simply call gtk_rc_parse() with
the appropriate filename. However, the styling rules applies in the
order they are loaded, then if we load our styles after GTK has loaded
the user's ones we'd override them.
There are 2 solutions to fix this:
1) set our styles' priority to something with lower than "user"
(actually "theme" priority because rules precedence are first
calculated depending on the priority no matter of how precise the
rules is, so we need to override the theme).
2) prepend our custom style to GTK's list while keeping priority to
user (which is the default), so it gets loaded before real user's
ones and so gets overridden by them.
One would normally go for 1 because it's ways simpler and requires less
code: you just have to add the priorities to your styles, which is a
matter of adding a few ":theme" in the RC file. However, KDE being a
bitch it doesn't set the gtk-theme-name but rather directly includes
the style to use in a user gtkrc file, which makes the theme have
"user" priority, hence overriding our styles. So, we cannot set
priorities in the RC file if we want to support running under KDE,
which pretty much leave us with no choice but to go with solution 2,
which unfortunately requires writing ugly code since GTK don't have a
gtk_rc_prepend_default_file() function. Thank you very much KDE.
Though, as a side benefit it also makes the code work with people using
gtk-chtheme, which also found it funny to include the theme in the user
RC file.
This allows for users to change the colors if needed (may be useful
with some themes or color blind persons).
On the sidebar, only the color is applied for now. This is because
it is not possible to style cell renderers through RC files, all having
to be done in the code; so currently only the color is applied.
This allows the user to override the custom styles we apply to some
widgets, like e.g. the unmatched search entry colors.
We use the :theme priority rather than the :application one because
it seems that the :application one cannot override theme settings, even
if it matches against a name the theme don't have rules for but have
rules for the class of that widget. This prevents a theme from
overriding our styles, but it's unlikely a theme actually provide some
specific stuff for us anyway.
