Resolves#11552
We did not explicitly define the colors for the Minimize,
Maximize, and Close button icons for merged titlebars.
On some system themes, the color used blends into
the titlebar and makes the icon look invisible.
This patch makes sure we always define the icon color
for the Default theme.
The .default style (to show which button is selected by
default) was being overridden by more general CSS styles.
This patch moves it after these general styles so that it
is shown again.
Based on user reports after the 3.0 release.
These leaks were most visible in the Preferences dialogue,
and cover too large checkboxes and radio boxes, wrong colors
for scrolled window backgrounds, sliders, scales, and
Preference Dialog headers.
While the slider colors match GIMP 2.10's light and
grey themes, the colors in 3.0 were inverted compared
to 2.10's dark mode. This patch inverts the dark mode
colors to better match 2.10's version.
Some system themes add additional padding or borders
to menu items when hovered over, which causes
the menu to jitter or shake. This patch attempts
to mitigate the issue by defining those values in the
Default CSS theme.
In collaboration with Denis Rangelov, the separator between
panes has been updated to use the same colors and thinner border
in all three theme variants.
Note that the border is created with box-shadow CSS, and is only
shown on one side of the horizontal separators to suggest that
it is a continuation of the bottom section.
On some system themes, the background color of
menu items on a merged headerbar would be a
different color from the rest of the menu when
GIMP's main window was out of focus.
This patch defines those items as clear so they become
whatever color the rest of the headerbar is instead.
Defines the background color behind
GtkNotebook tabs, removes the background
image from GimpSpinScale progressbar,
and specifies the padding and border width
for toolbuttons to prevent offset issues when
hovered over.
This patch prevents a system theme leak
for the "highlight" slider on GimpScaleEntry
widgets. Future work can be done to
improve the appearance of the slider.
Resolves#12821.
GimpSpinButtons (CSS spinbutton class) did not inherit the hover colors of
other buttons, so they did not highlight when hovered over. While comboboxes
mostly did inherit, there were a few odd instances where they were not in the
same hierarchy as other elements with hover colors defined. This patch defines
both explicitly to prevent one-off issues.
While testing an AppImage, I noticed a thick border around the
"Show All Files" in the File Open dialogue. This is because the
background color for the actionbar is not defined, and if the internal
padding is increased by the system theme, it's visible. Therefore
we define the color.
I also noticed that the GtkSwitch had a rectangle border rather than
a rounded one. This patch defines the border radius as well.
Resolves#12682
Some system themes add a gradient background-image to
text input and toggle widgets. On dark theme, this can
make the text unreadable if the background-image is a similar
color. This patch defines the background-image as none, to
prevent the system theme from leaking in.
The padding for image buttons on popovers like the layer lock
options was not defined. On system themes which set this padding
to 0px, it made it difficult to tell if the alpha lock was enabled
or not. This patch defines the padding to prevent this issue.
This patch adds CSS styling to define the color of the
underline/overline when dragging an item in a layer tree.
This prevents a system theme leak and keeps the color consistent
with the current theme's coloring.
We did not explicitly define the padding and margins for
the slider text and "progress" areas, which allowed for
system theme leaks. This patch defines these values and
makes the sliders visually closer to 2.10's style.
Like in #11964 for Default theme, the nib handle for the ink
tool is invisible on the System theme. Fix this by adjusting
the solution in a4f9e7e89a for use with the System theme.
In 9b917b8d, we defined the background and hover style
for the top menubar context menus. However, this did not
carry over to the menus for the on-canvas context menu.
This patch generalizes the CSS style so it affects both.
The Default box.vertical style covers up
the Sample Point indexes that are drawn
with Cairo. This patch adds a style for the
GimpSamplePointEditor that sets its inner
box.vertical to transparent in order to
to make the indexes visible.
Symbolic layer tree icons are often invisible
when not selected on System themes in
light mode. This patch adds a CSS rule
to ensure the layer tree icons are visible
on light backgrounds.
Per Anders Jonsson, removing this fixes
the issue with the grid colors on System
themes. As it does not work anyway
(the grid would be red if it did) and the
theme code is much better than it was
six years ago, lets remove it.
We didn't have a "destructive-action" class anymore and the
"suggested-action" was hidden by further CSS rule, so it needed to be
moved down so that it gets precedence.
We used to have these as red and green buttons originally (e.g. pasting
as floating selection, the "New Layer" and "Anchor" were the suggested
actions, i.e. green, whereas "Delete Layer" was destructive, red). For
GIMP 3.0, we keep grayscale design. We'll see if this will change later,
but at least, now we have something again.
Previously, the "menuitem menuitem" style was cascading down
to the top menubar's subitems. This patch explicitly defines the
CSS to match the 2.10 style and prevent cascading.
The color for the nib handle is pulled from
the widget's background-color style.
However, this was not defined - so it was
always (0, 0, 0).
This patch adds a GimpBlobEditor CSS
class and defines the background and
border color for it to resolve the issue.
This widget is used primarily in plug-ins like GFig and IFS Compose
which have toolbar buttons. This patch explicitly defines the style to
prevent system theme leaks and too dark colors on Middle Gray theme.
Inspired by Mark Sweeney's work.
This patch allows the active image, brush,
pattern, and gradient areas in the toolbox
to scale based on user icon scale
preferences.
Note that if the pattern itself is smaller
than the icon size, it currently won't scale
larger. This is a separate issue in the
renderer.
Resolves Issue #9955.
GimpToolDialog CSD buttons were being singled out to only
have padding of 2px. This was inconsistent with other dialogues
without this constraint. Since the larger padding style seems to
be preferred, we'll remove the constraint for GimpToolDialog
CSD buttons.
Resolves#11531
GtkListBox's CSS was previously defined, but GtkListBoxRow
did not inherit those values. This patch explicitly defines this
so we do not have system theme leaks.
Resolves#11337
"gtk-icon-shadow" is applied to all buttons with images,
which creates a bold effect on symbolic icons.
This patch zeroes this effect out and makes them highlight
the background in the same way as the toolbox buttons.
Resolves#11244
GtkRadioButtons can also have the .text-button CSS class set. This class was overwriting
the radiobutton background color, making it appear dark and box-like.
This adds a specific radiobutton.text-button definition to ensure the background color
is consistent (as we had to do with checkbutton.text-button)
Resolves#9795
(Solution provided by Andreas G, @uriesk)
Some system themes provide errant values for tooltip
box-shadows which cause flickering effects.
This patch defines the tooltip box-shadow to 0px to
prevent the issue.
As shown in a video for issue 11087, some system themes
may add a white box-shadow on the side of unselected
tabs. This patch forces box-shadow to "none" to prevent
this.
I believe there is a real use case for darker or lighter themes, but this
particular theme is not particularly maintained and has no light variant (or to
be accurate: the light variant is just a link to the "Default" one). If someone
is interested in such themes, we'll welcome contributions to revive a new theme
which should have at the very least both a light and dark version, and we could
name it "Contrast" (rather than "Darker" which focuses on a dark variant only).
I think it's better to do it this way rather than releasing with a half-done
job.
The Compact theme code is nearly the same as the Default one, apart from setting
palette icon size to small (which is already something done by the "Override
icon sizes" setting in Preferences), setting font-size to small (which can be
independently set by our "Font Scaling" setting) and setting 3 paddings.
Rather than having this separate theme, it feels like just moving the padding
changes as part of the icon size makes sense. In particular since, when setting
icons to "Small" right now, the default padding really feels a bit huge and out
of place. So all-in-one seems a better choice.
At first, I wanted to set a padding proportional to the icon size, but it didn't
work well. For now, I'll just choose padding sizes manually.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
If a system theme sets the background-image property for stacks,
it recolors the main canvas when empty. It also adds a border to
the toolbox Wilber area.
Additionally, the Credits page of the GtkAboutDialog has odd colors
due to general viewport grid styles overriding the GTK default.
This patch fixes these problems, and adds a custom CSS class to
the GimpAboutDialog for current and future work.
This is intended to prevent system theme background-images
and borders from overriding those set by GIMP.
The minimum size of tabs is also explicitly defined.
Resolves#10477.
The dark theme box-shadow for buttons does not blend well
when hovering over it, compared to the light & gray themes.
This patch adds an additional CSS rule to make the box-shadow
no longer clash in dark theme.
