It seems I had forgotten some hardcoded color in there. I didn't notice it until
now, because it was not that bad in the few instances where it was shown (for
instance the comment field in export plug-ins), but I really realized there was
a problem with the Python console which was not too practical (white writing on
kinda light background).
I noticed some buttons had a bluish border, showing the system theme leaking
over our default theme. So I'm just overriding this with a grayscale color.
These 2 new rules are especially useful in dialogs so that you know what happens
when you hit "Enter". The "default" action (.suggested-action in GTK CSS) is the
action we set to be the active one by default. E.g. if you open a dialog and hit
Enter immediately, without touching any widget focus, this is what will be
activated.
The GTK CSS .default action on the other hand seems to simply be the button with
focus right now, which can be changed through Tab or other ways. If both types
of styles are visible, the .default one is the actually activated action (not
.suggested-action), which is why I make its style a bit stronger (solid rather
than dotted and a bit more opaque).
Also I discover the shade() function to reuse a color and adding it
transparency!
Checked buttons had a background using the @selected-color. This was because of
a too broad rule on `.text-button:checked`. Basically it looks like the broad
rules are not good because they sometimes override more accurate rules for
specific widgets.
I also make a few more rules a bit more accurate. Also I extend some CSS rules
for check and radio buttons.
We had some concept of slightly more extreme theme colors (i.e. darker in dark
themes) to color differently in some widget-in-widget cases.
For instance, we use this in the treeview list to separate it better from nearby
interface. But this extreme dark background may have been a bit "too dark", as
reported by Jacob. The goal is for this list to stand out, but maybe it was
standing out too much. Hopefully it's better now.
As a side change, I also add some borders to the top icon header (with "eye" and
"lock" icons) just above the list. I think it better explain the separation.
Just use an inverted logic for the selected text (i.e. white on black in light
mode, or black on white in dark mode). This is the usual logic for rendering
selected text anyway (except that we don't use non-grayscale colors, e.g. blue
background is common in system themes).
This was massively breaking GtkScale rendering. Or at least the marks (and mark
texts) added by gtk_scale_add_mark() were simply invisible.
I tried to figure why, staring at the GTK inspector and testing various CSS
rules to fix it without removing this line, but just couldn't make sense of it.
In the end, I'll just remove this line. It looks like in CSS (or just GTK CSS?),
it might be better to set rules on accurate widgets rather than too broad rules. 🤷
This linear gradient really doesn't render any feeling of "background"
IMO. I only initially implemented it this way because the underlying
theme seemed to use such gradient effect on headerbar for background
dialogs, so I wanted to test this.
Anyway simply using the "disabled" color seem to work well. After all,
the semantic is similar too (if it's in the background, a dialog can be
considered inactive in some way). In any case, the meaning definitely
comes across now.
Don't use it only on menus. For instance, there were disabled checkboxes
(and their label) in plug-ins which were not showing different at all,
and it's confusing. Now both menu items, and other type of settings will
show similar "disabled" style.
… variant.
Now with my recent code, instead of creating 2 different themes, I make
it a single theme containing both a Light and Dark variant.
I move all semantic logic into common.css which will be included by both
variants after they set up their color definitions.
For choosing the basic gray to use for the dark variant, I first looked
up what is usually recommended. Most articles on the web about dark
themes would cite some "Material design" project (apparently originated
from Google) which makes guidelines for Android/iOS/Flutter and web
applications. Their guidelines recommend #121212 ("Dark Grey") as
background color. I tried, it's **really** dark. Maybe I'm just not used
to it, but it feels like it might be OK for small phone "apps" which
people might want to watch in the dark, but possibly not for a full
grown desktop software. I don't really know, I might be wrong and some
people might want to edit their pictures with such dark GUI.
Anyway for now, I settled for a base background #303030, which is
already quite dark, darker than Adwaita dark or than our 2.10 dark
variant, but at least doesn't feel like a black hole.
Since we have many themes now, this new name better indicates that it
is meant to follow your desktop theme settings.
Also it will likely not remain the default theme.
A few icons are still hardcoded in the Default theme. I am not sure why
they are not taken from the icon theme, but anyway let's fix the errors
for now.
to the search path. The index.theme is a copy of the upstream hicolor
index.theme with our custom sizes added, and it has to be first in the
path to be used at all. This. Is. Broken.
Rename them and move them into folders, e.g.:
stock-foo-16.png -> 16/gimp-foo.png
This change only moves internal stuff around,
it's not visible on any API.
The Align Tool had to be used in a very hacky way if one
intended to evenly distribute items across an image,
or other reference object (it would actually require one to
calculate the item spacing out of GIMP). This adds vertical
and horizontal fill modes: the reference object is divided
in N equal segments, where N is the number of items,
and each item is placed in the center of one of
these segments. The existing "offset" parameter
is used as an extra margin for the distribution,
and can be set to negative values, so that the items can
even get moved outside the boundaries of the reference object.
* themes/Default/images/tools/stock-tool-colorize-22.xcf: Edited the color of the yellow circle and changed it to green.
* themes/Default/images/tools/stock-tool-colorize-22.png: regenerated.
Move the Image Selection Menu from GimpMenuDock to
GimpDockWindow. That is, if a dock window contains many docks then
they will share the same Image Selection Menu.
To do this we need to move around quite a bit of code. Move the
"context", "dialog-factory" and "ui-manager" properties from GimpDock
to GimpToolbox, GimpMenuDock doesn't need it any longer. Turn the
GimpDock getters for these properties into wrappers that go to the
GimpDockWindow properties. In some places, most notably GimpToolbox
construction, we use the GimpToolbox values of these properties, but
most of the time it works fine to just use the GimpDockWindow
properties. GimpDock::setup() and set/get_aux_info() have also been
moved to GimpDockWindow since the only aux info for docks was for the
image selection menu.
Also, we don't bother porting gimp_menu_dock_destroy() to
GimpDockWindow, but we leave the code around. If this is a problem, it
will show.
To make the smaller font in docks also apply in single-window mode,
move the GimpDockWindow::font-scale style property to GimpDock. We use
the GimpDockWindow approach, so now each GimpDock has a name of the
form "gimp-internal-dock-<id>". We add "internal" to avoid clashing
with the GimpDockWindow legacy id "gimp-dock-<id>".
