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.
This continues the theme definition work from bd398d5c.
A new edge-border-color tag was created
to allow for defined widget edges in both
light and dark themes.
The box-shadow highlights for buttons
and header/menubars was defined to
reduce system theme leaks. Some CSS
attributes were rearranges as well.
Adds specific definitions for some widget borders that
are currently only defined by the system. This avoids
clashing colors depending on the system theme.
Resolves#10033
Not all system themes set a GtkRadioButton border-radius, so it
can default to 0. This creates a "box" around the radio button.
This patch defines the border-radius at 100% to make it universal.
As shown in issue 10287, the system theme can create a
large white border around GimpSpinButton.
This patch fixes this, and also improves the border appearance
by assigning it to the background color rather than system default.
Resolves#9989
In 2.10/GTK2, clicking an already selected toolbutton caused the
background color to change to indicate this action.
This patch restores that behavior through CSS updates.
It also slightly rearranges the CSS to group related button styles.
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.
Alx Sa