Resolves#9996.
While GIMP has background-colors set for specific buttons,
it did not have a default button background-color. This resulted
in "random" buttons showing system theme colors like the
[Reload Current Theme] button.
This patch defines a default background-color while leaving the
specific button themes intact.
This adds a border when hovering over icons in various
grid views (brushes, gradients, etc). This makes it more
visually apparent which option you can click to select.
Resolves#8756 (along with !1065)
The system theme leaked due to the checkbox styling not being
defined for GtkTreeView checkboxes.
The background-image in particular overpowers other settings.
The normal checkbox styling is now specifically applied to
these checkboxes as well.
Resolves#10015.
The border color of the menu checkboxes was not
specifically defined by the CSS stylesheet, causing
the boxes to appear invisible when unchecked in
certain system themes. This defines the border color
to the same as the menu text to ensure visibility.
Resolves#10007.
The menu separator color was not defined in the stylesheet,
so it could vary based on the system stylesheet.
It is now set to @stronger-border-color.
Resolves#10040.
A System Theme leak could cause a large border to be drawn around
the export options at the bottom of the Save Image dialogue.
This patch defines them specifically as 1px border with the
@strong-border-color CSS styling.
Resolves#10000.
The border around notebook headers was not specifically defined in
GIMP's CSS stylesheet, so if the system theme used a different color this
would also change. It has now been defined as @strong-border-color.
The existing CSS was also moved to the same area as the other notebook
header definitions.
Resolves#10020
For some reason, not having the border-radius CSS style set
in widgets inside scrollwindow viewports causes them to have
a giant black order if they're not a full height. This was previously
fixed for GtkGrids. This patch fixes it for GtkBoxes as well, such as
the Procedure Browser description area.
Adds a class "gimp-offset-area-frame" to the frame containing a GimpOffsetArea in resize dialogues.
This allows the styling from 2.10 to be applied to indicate canvas size when resizing layers.
Since GimpOffsetArea is a GtkDrawingArea object, it can't have CSS directly
applied to it - that's why the class is added to the frame instead.
...the tab itself. Noted by @user062. This adds a right margin to the
close button on the image tabs so that the tab size is pushed out
to fit the button.
The combo box button is contained within a box element.
The box was also having its background-color set,
so there were small square "corners" around each dropdown menu.
This patch separates the box color from the button color to prevent
this.
Resolves#9676.
Per @pixelmixer and @programmer_ceds's research,
setting the color attribute on the switch's image children
removes the 1/0 labels on non-System themes.
The previous commit did fix one such reason (multiple separators next to each
other), but I realized there is one other case where single separators are just
too big: when the menu is embedded in a GtkHeaderBar, each separator would have
a weird margin of several pixels (at least in my case, probably taken from the
underlying system theme). And worse, this margin was using another background
color.
So anyway this CSS rules takes care of not adding weird margins to menu
separators.
The checkbox label wasn't included the :hover CSS, so its background
color didn't change. This created a "box" around the label without the
highlight color when the mouse was over it.
This patch does the following things:
- An option "Merge menu and title bar" (this is hopefully more understandable
than calling it "Client-side decoration" or again "header bar") is added in
Preferences > Image Windows. This option triggers the restart warning.
Moreover when checked a small warning message will tell that in some cases, it
may not work (there are feedbacks of people having 2 title bars when using GTK
applications using CSD).
- For the reason evoked above (sometimes 2 title bars) and also because the CSD
concept seem really to divide people a lot (some love this as much as others
hate this), this new option "custom-title-bar" on GimpGuiConfig is FALSE by
default.
- When the option is checked, the image windows will use a GTK header bar
containing the menu, the window title (image name and information) as well as
the usual minimize/maximize/close buttons per your OS conventions.
- Since the header bar is set to be hidden when maximizing, if you checked "Show
menubar" for the "Default Appearance in Fullscreen Mode" in Preferences >
Image Windows > Appearance, the menu will be moved to its "old style"
position, i.e. above the canvas. This makes the menu possibly visible (if
relevant option is checked) even in fullscreen mode.
- I tweaked the Default theme to show the header bar with minimal height,
because I find GTK default theme's headerbar height unreasonably high
(especially if the point of the header bar is to save screen space). I am
unsure if this was the right move though, because maybe the default theme
should not do such choices (maybe this should go in the Compact theme?).
What we call "System" theme should have very minimal edits over the
actual system theme. So let's drop all the "font-size" properties (one
"larger" one, but especially the many "smaller" ones).
This means that the "Default" theme also will keep system font size.
This is as discussed with Ville and Liam, the later saying he can barely
read dockable texts because of this.
On the other hand, we use "small" font size as a general rule in the
"Compact" theme, which is especially meant for people who want a compact
theme.
The Default theme may have been a bit too dark. Instead let's have it a
tiny bit lighter (and also foreground color a bit less white).
For now, the old "Default" dark theme doesn't disappear totally and is
moved to a "Darker" theme as we have been discussing and wondering on
whether this is prefered by some people (it is). Aryeom also thought a
darker theme may be a good idea.
Moreover Liam actually thought that losing some of the contrast
(especially with the text a tiny bit less white now) is not desired in
his case where eyes may not be as sharp as they used to. Therefore a
"High Contrast" theme may be needed.
Aryeom also suggested that sliders to choose colors could be a much more
generic solution, which might be possible yet would require more ugly
hacks generating on-the-fly theme changes (we do something similar for
dark theme choice already).
This is all work-in-progress and a result from Wilber Week 2023 work.
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. 🤷
So what we read on the topic is to use (as base color) the gray which is
perceptually half-way between black and white. Unfortunately it can mean
different colors. For instance if using the sRGB TRC, the #808080 color is
sometimes cited.
Instead I went with the color LCH (50, 0, 0), i.e. with half perceptual
lightness in "CIE LCH(ab) float" babl space, i.e. #777777 in sRGB. It
corresponds to the 18.42% gray which is often refered to, so it seemed a fine
choice.
This replaces proposal in !683 because the contributor is not responding
anymore, and also it uses the common theme base CSS files used by all other
official themes.
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.
Something which is regularly asked is to use smaller icons. We used to
have a "Small" theme in 2.8, which got away in 2.10 with icon sizing (cf
issue #6121).
This is a revival of such a theme (except I call it "Compact" because it
feels more appropriate than "Small"). The theme is basically the same as
"Default" (through an include), just tweaking some size related CSS
rules.
… 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.
Instead of hardcoding the colors in CSS rules, make variables of them,
with meaningful semantic names. It will help with making consistent
design where a color means something and is reused in several places
(e.g. a color for "hovering" or "selecting").
I add some variants but not too much (e.g. treeviews had even lighter
background, with an inversion of logic, where selected items are on
darker background instead of lighter).
Colors in this theme are mostly the same before and after this commit,
except for a few parts where I felt that having more variants was
detrimental for consistency and maintenance.
As part of the changed colors:
- check and radio buttons' background just reuse the lighter background
color (as used e.g. in treeviews and entries).
- menus also use this lighter background color with the color inversion
(same as treeviews) for hovered items.
This commit also brings some improvements to disabled cases:
- Stylize also disabled tree view items (e.g. disabled actions in action
search were styled the same way as runnable actions).
- Stylize the same way disabled buttons drawn directly or with an image
widget.
The last use for this change is that it will help to create a dark
variant for the same theme using nearly the same code, hence get
consistent styling.
- Indent all rules in Light theme with the same number of spaces for
style consistency.
- When GIMP was set in "Prefer dark variant", spin buttons and other
entries had too dark borders. Fix this.
- Fix the spinbutton entry's border radius which was at 0, but since the
buttons of the spin button are themselves rounded, it looks weird only
on the top and bottom left corners. So apply a 3px radius. I did this
in the System theme.
Makes the following changes:
*Toolbox Wilber is now visible
*Large black border removed from ScrolledWindow
*"Duplicate text" effect removed from labels
*Toolbox tabs are now stationary when changing selection
*"Add Tabs" menu background color changed to match Light theme
*Unnecessary border around Check Updates box removed
These are issues which appeared to me only when GIMP was set to use the
dark theme variant. In such a case, I guess we see quite well CSS rules
coming from parent themes, such as the globally set system theme.
* Remove any background image (which may come from the system theme?) on
buttons.
* The headerbar was dark and when in the background, it had a dark
linear gradient (probably coming from my system theme). So make sure
the background color is right as a general rule, and add back a
(small) light gradient to indicate the background state.
* GtkListBox had a dark background. We don't have a lot of usage for
this widget yet, but a few (for instance in icon theme settings, or in
the modifiers editor).
* The GtkSwitch buttons were dark on dark. Set a light background. Also
when the switch is ON, I add a bit of color, not too strong, but
enough to indicate the checked status, because I find this widget
design not so obvious. Since I don't think we use switch buttons
anywhere else but in Preferences, this is probably not a big problem
as it should not affect color perception when working on the canvas.
There were some complaint about the height of these scale.
The min-height was clearly too high. I also made the buttons a bit more
compact by removing a bit of padding.
Finally I add a CSS name to the class, in order to avoid using the
parent class name ("spinbutton"). This makes for clearer and more
customizable themes (ability to style the GimpSpinScale without styling
GtkSpinButton too).
In gimp.css, don't set a minimum height for GimpDisplayShell
statusbars. Instead, in GimpStatusbar, set the widget's minimum
height to the maximum of its children's natural heights. Note that
we have to do this manually, instead of using a size group, since
GtkSizeGroup::ignore-hidden is deprecated (and nonfunctional) in
GTK3.
Alx Sa