has no alpha, simply fill the mask with complete opacity instead of
leaving the user with a completely empty mask (and thus a completely
transparent layer).
We need the gir and plugins to be able to generate the splash image(s).
Add those as dependencies to gimp executable to ensure they are there
when needed.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/13657
Resolves#13889
Adds support for exporting palettes in
Krita's .kpl format (zipped .xml data).
Colors are currently saved as 32-bit
floating point RGB values.
Future work includes supporting other
color spaces like CMYK, other precisions,
and including color profiles for colors.
Similar logic to 4d8073a3 - the selection signal was not
being properly disconnected when the dialogue closed after
the color entry's color was changed via the HTML field.
This patch switches to using g_signal_connect_object ()
to automatically disconnect when the object is destroyed.
Currently, the Jigsaw plug-in only draws on RGB
channels. If the alpha channel is 0, then the Jigsaw
pattern will not show because it does not change the
alpha channel.
This patch adds a check if the format has an alpha
channel, and conditionally sets the alpha byte to 255
when drawing to ensure the pattern is always visible.
This patch also does some formatting clean-up, and
adds a check on the final progress update when previewing
to prevent it from showing 100% as soon as the GUI appears.
… follow theme colors or not.
This is an update to MR !1370, as a result of testing and usability
meetings with Aryeom. While we understand that some people may want the
brush dockable to not display as some huge white "stain" in the middle
of an otherwise dark GUI (or other colors, depending on the chosen theme
and color scheme), brushes are not part of the GUI. When you look at
brush previews, you don't expect these to follow theme. And for sure,
painters more often paint over a white canvas than a gray or dark canvas
(or other colors), even though this is not an "always true" either. But
it's probably a better bet than following theme (which is closer to
"always false"!).
Therefore, what this additional commit does:
* By default, the brush previews still show as black on white;
* Nevertheless there is now a button (using the Preferences' theme icon)
in the Brushes dockable which allow to switch to theme colors
following brush previews.
* This setting is a GimpGuiConfig property, which means it will stick
across sessions.
Previous code was using the correct background color from the theme, but
the foreground color was always either white or black (depending on GUI
config color scheme). Instead, just use the foreground color from theme.
Since core/ doesn't have access to GTK, hence the theme, we had to
update GimpViewable's get_preview() and get_pixbuf() abstract methods to
have a color argument for recoloring previews (when relevant, which for
most types of viewables is not).
background color. Resolves#9983.
We now check the parent widget's color
first to prevent issues with the selection
altering the background color of the
icon until the view is refreshed.
As a result, we can now define the
selected color of an icon, fixing a
regression from 2.10.
..background rendering. As with the
previous commit, this patch tries to
retrieve the background color and color
properties of the widget, then use them
to draw the background and grid of the
Palette and Colormap dockables.
since GTK 3.10 and according to the GTK3 documentation the setting
is ignored.
Remove the reference to it and thus setting a fallback. According to
the GTK docs `hicolor` is the fallback icon theme.
Since `gimp_icons_notify_system_icon_theme` was only used to add
the fallback, remove the function and setting it with
`g_signal_connect`.
Photoshop stores their Levels filter presets in an
.alv file. This patch adds support for loading these
and converting them to GIMP's Level format.
The .alv file is binary, and consists of a 2 byte version
followed by 29 groups of 2 byte values for input,
output, and gamma. We only read the first four for
now, since GIMP only supports composite and then
R, G, and B individual channels.
Photoshop stores their Curve filter presets in an
.acv file. This patch adds support for loading these
and converting them to GIMP's Curves format.
The .acv file is binary, and consists of a 2 byte version
and 2 byte curve count. Then, you read in 2 bytes for
the number of curve points, followed by 2 bytes for
the Y value and 2 bytes for the X value. You repeat that
for the curve count defined in the header. PS Curves range from 2 to 19 points total.
Since we did not define the padding between menu items
in the menubar, some system themes caused them to
scrunch together. This patch sets the padding to match the
"default" GTK CSS to ensure there's distance between each
item in the menubar.
This patch reduces three sets of warnings
when compiling on Windows:
* In gimp-layer-modes.c, we move the
g_return_val_if_reached () in
gimp_layer_mode_get_format () to the
default case in the last switch statement
to prevent a warning about an unhandled
switch case
* In spline.c, we initialize V[] to prevent
a warning about uninitialized values
* In flame.c, we unconditionally call
g_bytes_unref () to prevent a warning
about dangling pointers.
Right now, when you were setting your hints as KEEP_ABOVE, the dock
window would only keep above the image window from which you called it.
If you create a new image window, it could hide your toolbox and dock
windows.
Now we will reparent the dock windows when switching active display.
Note that this also applies to other types of dialogs we have, such as
the New Image dialog or the Search Actions, etc. But looking at all
these factory dialogs we have, it doesn't look like there is a single
case where the parenting pertains to a specific image. So it makes sense
that we always reparent when focusing a different image window.
Per testing by Gabriele and discussions on IRC, it doesn't make sense
that UTILITY windows also keep all dockables above. Otherwise what's the
difference with KEEP_ABOVE?
Also it turns out that on macOS, setting a parent makes the transient
window follow the parent window (so it's close to the modal window
concept of GNOME). So that makes it even more important that our utility
windows don't have a parent.
Previously, we set text color to change when the "color-changed"
signal was sent out from GimpColorPanel. When all of the text is
the same color, this works fine. However, if we select text with
different colors on the canvas editor, the color defaults to black
since we can only hold a single color. If the user cancels, the
"color-changed" signal is still sent out, so we change all colors
to black.
This patch changes the code to use the "response" signal instead.
Then, we check if the user chose "OK" before calling the color
change function.
To balance the child areas in the toolbox horizontally,
we dynamically set the maximum number of children in
the GtkFlowBox depending on the number of visible ones.
It is possible to hide all of them, giving us a max count of 0.
However, gtk_flow_box_set_max_children_per_line () requires
the max count to be at least 1 - this causes a CRITICAL.
This patch adds a check to make sure the count is at least 1
before calling that function.
