gimp_file_proc_view_process_procedure() can return NULL in case a file
loading procedure does not have any extensions set.
(cherry picked from commit 073a7a208f)
By being in GimpContainerIconView, the toggle was only being shown in
grid view, even though it also affected the list view. So we move it up
to the container, next to the query tag entry.
Also I am adding a function to make this toggle visible only when
requested. And so far, we only request it for the Brushes dockable,
because it doesn't do anything on other data dockables (we added some
code to follow theme, for instance in Palettes dockable, but it doesn't
depend on this setting, because it doesn't touch data render, only GUI
render where it's normal to follow theme).
The latter function fixes issue #14260.
(cherry picked from commit 1b9c78dc12)
This patch removes restrictions on applying
NDE filters to channels in the GUI. Note
that layer masks are still restricted, not for
technical reasons but because UX/UI needs
to be considered further.
(cherry picked from commit 54c95577df)
Resolves#14206
If the user clicks the Fx icon in the DrawableTreeView
repeatedly (and quickly enough), the "closed" signal
function that cleans up the Filter popover does not
run before the next creation code is started. This can
results in the previous view being left in editor->vbox,
leading to duplication.
This patch checks if the editor and view already exist when
the popover opens, and if so, it runs the clean-up code first.
(cherry picked from commit 6e58d05a56)
It is unused and setting it on the new toggle button doesn't seem to
work anyway as the dockable's help ID is called. Improving the help page
for this dockable, rather than adding a specific help page, seems a
better fit anyway.
(cherry picked from commit d45ff5b5cd)
Commit 80fca449a4 had a few issues:
- It was using the theme's foreground or background colors as non-entry
color, depending on whether we draw a grid or not. It should just be
the background's color.
- It was still defaulting color to white/black in some places, instead
of fg/bg colors (though I just removed these defaults because the code
just always properly set these colors later on).
- It was using the foreground colors for vertical grid lines, instead of
background color.
- It was coloring horizontal grid lines as black, instead of background
color.
(cherry picked from commit 0f900d2946)
The code was still assuming that GimpTempBuf is always 8 bit. Fixed
that, and optimized it to call babl_process() once per line instead of
per pixel. Fixes#13253.
(cherry picked from commit 6151deaff9)
instead of using the property dirtectly. Also make sure temporary
filters don't go to the undo stack or to the XCF.
(cherry picked from commit 2baab5aa74)
editable filters, regardless of whether they are currently editable.
Also an ugly hack to make sure the popover resizes corrently with the
number of filters.
(cherry picked from commit 90db039270)
- move the filter popover to its own file
- centralize popover sensitivity settings
- get rid of gimp_item_refresh_filters()
- lots of minor filter fixes/changes
(cherry picked from commit 27b09025be)
Many actions done on layers require refreshing its filters, by toggling
the layer off and on again. When done on an invisible layer, this would
turn it visible, which could not be undone.
Now, the layer remains invisible.
(cherry picked from commit a60c1097ab)
Layer Masks", Fixes#14055.
- change the logic to show the toggles in "on" state ONLY when ANY
selected layer has the property enabled.
- adjust the action callbacks accordingly, and fix them to only push
undo groups when multiple layers are changed.
- completely remove gimp_layer_tree_view_update_menu(), which did the
same as the action update code, only more broken, was causing
redundant undo steps beibng pushed, and was probably obsolete for 20
years.
(cherry picked from commit c460450b4a)
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.
(cherry picked from commit 5918e2b4d3)
… 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.
(cherry picked from commit b45cb600fe)
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).
(cherry picked from commit 3038c751bc)
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.
(cherry picked from commit 9bef3b2edd)
..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.
(cherry picked from commit 80fca449a4)
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.
Resolves#14047
The Color Dialog that appears when you select a
text outline color does not load a palette from context.
Since we then try to get the name from a NULL palette,
this causes a crash.
This patch resolves the issue by adding a check for the
palette's existence before trying to get its name.
A GimpColorFrame's GeglColor's Babl format's precision is set to the image's precision
when picked. On an Image encoding change to a different precision the colors are
perceptually identical, but for Sample Points set to 'Pixel' we need to run
gimp_color_frame_update after updating the frame's color to the higher precision one.
windows‑display* actions are used to switch open displays and are not
meant to be remapped. They are implemented so they can be reassigned
each time a display is opened, closed, or moved, in order to keep them
aligned with the order of displays. This commit hides them from the
Shortcuts dialog to prevent remapping and avoidinconsistent behavior.
To avoid hiding these actions completely and making them harder to discover,
this commit removes them only from the shortcuts dialog while still showing
them in the action search.
(see #11685)
For some GUI elements, we may not want to restrict
the color options to the image mode (for instance,
grid colors on a grayscale or indexed image).
This patch adds a "user_context_aware" boolean
to GimpColorPanel so it can be passed on to set
the same boolean already in GimpColorDialog.
This allows GUI elements like GimpGridEditor to
optionally give full color choices to users,
independent of the image mode.
...color-picking on the image.
In GIMP 3.0, we now show a GimpColormapSelection when
users open a color dialogue. However, unlike the RGB color
selector it does not respond to color-picking, instead always
defaulting to index 0.
This patch adds code to get the index of the currently selected
color from the palette, and set the ColormapSelection's selected
index to that.
47224ba1 set the number of children in the GtkFlowBox
that holds the toolbox widgets to a constant 3. However,
this means if you only have one or two widgets shown,
there was still a horizontal imbalance.
This patch adds up the number of visible widgets whenever
that is changed, and adjust the maximum number of flowbox
children accordingly. It does add a small amount of padding at
the bottom since the invisible widgets are moved below.
Note that I also tried to set the monitor as a weak pointer, but it was
not properly finalized by GDK at disconnection apparently. Anyway
processing the "invalidate" signal is a correct way to do this too.
A further possible improvement may be to store the description of the
monitor in the sessionrc file, and keep these in the GimpSessionInfo
too, so that we can easily retrieve a monitor which is often
disconnected and reconnected.
Fixes issue 5176.
In GIMP2, the window hint preference controlled whether the image
window was allowed to draw on top of the Toolbox and docks.
In GIMP3/GTK3, apparently that hint does nothing; it's transient-for
that controls that behavior. This patch uses the transient-for
setting only if dock_window_hint is set to GIMP_WINDOW_HINT_KEEP_ABOVE.
The tool group tooltip was not updated when users
toggled the visibility of tools in Preferences. This patch
adds a check before adding a tool to the tooltip, to make
sure it's visible first. It also clears out tool group tooltips
on mouse over to ensure the tooltip is updated.
The "Available Filters" scrolled window was locked to
200px by 100px when the Display Filters dialogue is
opened. Since this size restriction is unnecessary and
makes it difficult to see the actual filters, it was removed.
The "Active Filters" still restricts the height (with scrolling),
since you can add multiple copies of the same filter
to the display.
We use GEGL filters for some of our currently destructive
editing only tools, like Warp and Bucket Fill.
While eventually these will have non-destructive options,
for now it's confusing to show an Fx icon briefly when
the tools are active.
This patch sets these filters as temporary, and updates
the GimpItemTreeView code to not show the Fx icon
if there is only one filter and it is temporary.
Temporary filters can not be deleted from the NDE
pop-up, only from their tools, preventing another set
of reported crashes.
for generated brushes.
The maximum radius we allowed for generated brushes was not used
consistently everywhere.
In the API call we clamped it to 0.0-32767.0, while the param_spec
set min and max to 0.1 and 4000.0, and the brush editor used a
maximum of 1000.0.
Using a large value (probably anything larger than 4000) would
sooner or later lead to a crash.
Instead of manual changes everywhere, let's define a maximum and
minimum in one place and use that wherever we need the min/max values.
Use the values as set in the param_spec for the defines.
The only place we can't easily do that is in brush.pdb, so we add
a comment above our defines that the values need updating there too.
Actually we should probably use more defines for other values too,
that way there is less chance of min/max values getting out of synch
throughout our code.
