When removing a GimpContainerTreeStore item, make sure that editing
of corresponding tree-view rows is canceled first, by emitting a
"row-changed" signal. Otherwise, we can run into trouble when
removing an item that is being edited.
I was directed by Massimo to some bug which was repeatedly generating
dozens of thousands of GEGL WARNINGs and that was completely taking over
the GUI if redirected to GimpErrorDialog. Currently GEGL warnings are
not redirected there, but the problem is still there, and we don't want
GIMP warnings to freeze the whole GUI either.
So only increment the repeat variable upon gimp_message_box_repeat() and
delay actual GUI update to a later low-priority idle function.
I actually think the buttons were translatable, but the strings were
simply not auto-extracted with previous code (which is nearly the same
in the end). Should be better now.
Since commit 9fdf35550b, I removed the GIMP_APP_GLUE_COMPILATION check
because we need to have the whole versioning info from the new debug
widget. It just makes sense to go further and just make this a proper
internal API to get version information.
This is obviously not possible anymore to do this manually so this step
is bogus in a crash case. We keep this step for other (non-fatal)
errors. We may add an automatic "attempt" to save in a backup file
later, which may not work depending on how bad the crash is (which is
why it will be done in a backup file, we don't want to corrupt saved
files).
It was previously untested, hence as expected needed fixes. First I add
our own exception handler using Win32 API SetUnhandledExceptionFilter().
Second, I reorder things so that ExcHndlInit() is run after this setter,
since they will be executed as a FILO and we need backtraces to be
generated before our separate GUI runs. Last I run the backtrace GUI as
async. No need to keep the main GIMP waiting since the traces have
already been generated into a separate file.
Also replace gtk_show_uri() by the implementation taken straight from
our web-browser plug-in, since apparently gtk_show_uri() doesn't work in
Windows (and probably not macOS either since I see we have a separate
implementation for this platform as well). I would like to be able to
use the PDB but can't because this code needs to be usable both within
the main process and into a separate tool process. Ideally, this should
just be a utils function which could be included without a problem.
* Type pid_t is not cross-platform. Just use int instead, and convert it
to respective type on each platform.
* Get rid of several useless include which should have been removed a
few commits ago, when I reimplemented the backtrace function.
* Better handle the various macros in gimp_eek() (between G_OS_WIN32,
HAVE_EXCHNDL and GIMP_CONSOLE_COMPILATION, but also no_interface and
generate_backtrace options, that was a bit messy).
* Make gimpdebug now always built, whatever the platform.
This was a bit harder since even though we handle fatal signals,
allowing us to do any last action before GIMP crashes, it seems more
memory allocation is not allowed at this time. So creating a dialog or
simply getting the return output of gdb into the main process is not
allowed. What I do instead is running a separate program (gimpdebug)
which will take care of creating the new dialog and running a debugger.
I still use GimpCriticalDialog code from this separate binary, while I
continue to use this widget also within GIMP for non-fatal errors. The
reason why we still want to use it within GIMP is that we can bundle
several non-fatal errors and backtrace this way (fatal errors don't
return anyway) and it's easier to do so when created from the main
process.
GIMP will now try to get a backtrace (on Unix machines only for now,
using g_on_error_stack_trace(); for Windows, we will likely have to look
into DrMinGW).
This is now applied to CRITICAL errors only, which usually means major
bugs but are currently mostly hidden unless you run GIMP in terminal. We
limit to 3 backtraces, because many CRITICAL typically get into domino
effect and cause more CRITICALs (for instance when a g_return*_if_fail()
returns too early).
The CPU group monitors GIMP's CPU usage, and can measure the amount
of time the CPU has been active, which can be used to get a rough
estimate of the execution time of certain operations.
Be warned: while the CPU group is available on *nix and Windows, it
has only been tested on Linux.
Allow controlling the gauge/history visibility, and the history
interpolation method, of individual values.
Improve redraw elision when some values are hidden.
The four remaining "classic" color tools (Brightness-Contrast, Curves,
Levels and Threshold) are in fact just special UIs for otherwise
completely normal filter ops.
Add normal filter actions for them and invoke them like all
other filters, which makes them show up in the filter history
automatically.
The only small hack needed is to special case them in
gimp_gegl_procedure_execute_async() so the right tools are created
instead of the default GimpOperationTool. Also, blacklist the
automatically generated tools actions from action search and the
shortcut editor.
gimp_action_history_init(): when deserializing the action history,
check each action against gimp_action_history_excluded_action() so
when we decide to exclude an action, it doesn't come back as history
zombie from disk.
...on the list dialogs on the Input text area
gimp_container_editor_constructed(): connect the container
view's "select-item" with G_CONNECT_AFTER because the signal
is G_SIGNAL_RUN_LAST. Some quick greps didn't find anything that
would be affected, except fixing this bug. Found by Massimo.
Looks like we should use L*, C*, and h° to stay consistent (in
particular Lab L* and LCH L* are the same value), and also to allow for
future implementation of variants of LCH.
Value "h°" was the hardest to choose since we sometimes see just "h",
sometimes with a star, and other times with a degree. Even reference
documents display the 3 versions in the same documents! I just went with
a 2-letter version with degree, as seen on Wikipedia, and to align
better with other 2-letter LCh values. That's pretty arbitrary and can
be changed if another shortened name is considered better.
Elle Stone says (cf. bug 791484, comment 9):
> there are several variants of "Lab" out there, with the most commonly
> used (and the version GIMP currently uses) being the 1976 version,
> which uses asterisks to differentiate it from the earlier "Hunter"
> version. So yes, asterisks are technically correct.
Better use the most conventional naming. And as a side effect, it makes
differentiating Lab a* and Alpha shortened names more obvious, while not
making them that much bigger (2 characters instead of one for "a*").
To mark them as different strings with a context, otherwise "B" for Blue
and "B" for Lab b* cannot be translated separately (for instance).
See commit 7ac7b9519f and previous commit.
These labels were shortened but it's difficult for translators to know
what they are, especially when same shortened labels are common to
different concepts.
See commit 7ac7b9519f.
Add "color-profile-path" to GimpDialogConfig to remember the last-used
path in any profile chooser dialog.
Whenever a GimpColorProfileChooserDialog is created, call a new
gimpwidgets-utils helper function that connects to the dialog's "show"
and "response" signals and makes sure "color-profile-path" is set on
the dialog if it doesn't have a current folder already, and sets the
property back to the config object when a profile was actually chosen
from disk.
...to allow more space for the channel values
to allow the Pointer, Sample Points, and Color Picker Information
dialogs to be narrower and still show the channel value, without the
channel value running over the top of the channel identifier.
Mitch: did even more and also split the coordinates display to two
lines, because on large images the widget's width was flickering
or the labels were overwriting each other.
Refactor GimpDashboard to autogenerate the UI based on a
description of the different variables, fields, and groups.
Allow individual groups to be expanded/collapsed, and individual
fields to be enabled/disabled. Save the relevant state in the
dashboard's aux-info.
Add fields for the new GeglStats properties, as per GEGL commit
25c39ce6c9bb618f06ac96d118e624be66464d74. The new fields are not
enabled by default.
Add "reset" action, to clear the history, and reset cumulative
data.
The dashboard dockable shows the current GEGL cache and swap sizes,
and their recent history. It has options to control the update
rate and history duration of the data, and an option to warn (by
raising/blinking the dialog) when the swap size approaches its
limit.
GimpMeter visualizes a set of values that change over time. It
consists of a gauge, showing the most-recent sampled values, a
history graph, showing a plot of the values over time, and an LED,
which can be used as a boolean indicator for some condition.
GimpMeter is used in the dashboard dockable, added in the next
commit.
It turns out we already have the support since it uses the same axis as
the "wheel", used by other devices (for instance the Airbrush pen of
Wacom has a wheel reporting on this same axis).
We can't do any fancy support for this right now, but at least we can
clarify a bit the dynamics naming so that people understands it can be
used for both wheel and rotation input.
Fix the various "Wheel" dynamics strings into "Wheel/Rotation".
Add gimp_item_get_merged_color_tag(), which returns the color tag
of the nearest ancestor (including the current item) that has a
color tag other than NONE. Use this function in GimpItemTreeView,
instead of gimp_item_get_color_tag(), to set the cell color of
items, so that item's with a NONE color tag inherit the color of
their parent. Add a boolean "inherited" parameter to
gimp_get_color_tag_color(), which indicates if the color tag is the
item's actual color tag, or an inherited color tag, and modify the
returned color accordingly, so that inherited colors are less
saturated/lighter than non-inherited ones.
Update the dprod production of generated enum files to include
abbreviated value descriptions, as per the previous commits.
Add a comment for translators above the abbreviated descriptions,
specifying the full description they abbreviate.
Add "In Place" variants for all sorts of pasting:
- extend the GimpPasteType enum with IN_PLACE values
- add the needed actions and menu items
- merge the action callbacks into one, taking an enum value as parameter
- refactor the pasting code in gimp-edit.c into smaller functions
We probably have too menu items in the "Edit" menu now, needs to be
sorted out.
When a display filter's configure() function returns NULL, use a
propgui for the filter, instead of not showing a widget at all, to
spare filters the need to manually construct a configuration gui.
When applying a relative adjustment to a spin scale, don't wrap the
pointer around the corresponding screen edge if the spin scale's
value is already minimal/maximal.
While applying a relative spin scale adjusment (i.e., when dragging
from the lower half of the spin scale), wrap the pointer around the
screen edges (of the current monitor), so that the maximal possible
adjustment amount isn't artifically limited by the screen geometry.
This is especially useful for spin scales in dockables, since
dockables are normally placed near the edge of the screen.
When the mouse is released, move the pointer back to its initial
position (at the beginning of the drag), to allow for subsequent
adjustments.
Unfortunately, moving the pointer programatically isn't supported
on all envrionments (Wayland, Xephyr, ...), and worse yet,
detecting that the pointer failed to move is tricky, so we have to
resort to an ungly hack to maintain the current behavior in this
case. Gah :P
Small fix to last commit: make the name entry editable when the
data is renamable, even if it's not otherwise writable (completely
hypothetical for now.)
Make internal data objects non-renamable, even if they're writable,
through gimp_data_is_name_editable(). Currently, the only such
object is the custom gradient.
Prevent changing the name of non-renamable data by making the name
entry of GimpDataEditor non-editable whenever
gimp_viewable_is_name_editable() is FALSE, even if the data is
otherwise editable.
Prevent the vairous PDB -rename() functions from renaming non-
renamable data, by adding a GimpPDBDataAccess flags type,
specifying the desired access mode for the data -- any combination
of READ, WRITE, and RENAME -- and replacing the 'writable'
parameter of the gimp_pdb_get_foo() functions with an 'access'
parameter. Change the various .pdb files to use READ where they'd
used FALSE, and WRITE where they'd used TRUE; use RENAME, isntead
of WRITE, in the -rename() functions.
Keep track of the selected viewable of a GimpContainerEntry, and
update the entry text when the viewable's name changes, if the text
hasn't changed since the viewable was selected.
Currently, the error console is highlighted (shown/blinked) only
upon errors; however, warnings, which are not shown on the
statusbar while the error console is open, often also contain
important information.
Allow the user to configure which message types (errors, warnings,
and regular messages) highlight the error console, using a new
"highlight" submenu in the error-console menu. Add corresponding
config options, saved in sessionrc. By default, highlight the
error console unpon both errors and warnings.
gimp_dockable_blink() is used to attract the user's attention to a
specific dockable. Generalize this to arbitrary widgets, by
replacing gimp_dockable_blink[_cancel]() with
gimp_widget_blink[_cancel](), in gimpwidgets-utils.c.
The GTK+ implementation of gtk_drag_higlight(), used by
gimp_highlight_widget(), paints a black box around the widget,
which is not very noticable when using a dark theme. Copy the GTK+
code (which is simple enough) over to gimpwidgets-utils.c, and use
the widget's text color for the box instead.
When changing the layer-mode group in a GimpLayerModeComboBox, check
the new mode against the combo's context, and fall back to normal if
it's not applicable. This is necessary for the color-erase mode,
which has both a legacy and non-legacy variants. The former is
applicable for painting contexts, so we want to map the non-legacy
mode to it when changing groups, however, it's not applicable for
layer contexts, so, in this case, we want to map the non-legacy mode
to normal.
Add an "expanded-changed" signal to GimpViewable, which should be
emitted by subclasses when the viewable's expanded state changes.
Emit this signal when the expanded state of group layers changes.
Respond to this signal in GimpContainerView, by calling a new
expand_item() virtual function. Implement expand_item() in
GimpContainerTreeView, expanding or collapsing the item as
necessary.
When the mouse hovers over the upper or lower half of a spinscale,
highlight the corresponding area, to hint that the two halves
behave differently. This seems to cause a lot of confusion, so the
different cursors are apparently not enough :P
We use a low-opacity version of the current theme's text color for
the highlight, since it should have a good contrast to both the bar
color and the background color.
Increase the step and page increments of the brush radius spinscale
in the brush editor to 1.0 and 10.0, respectively, to match those of
the corresponding spinscale in the paint tool options.
Add gimp_color_panel_dialong_response() to GimpColorPanel, which
emits a response for the color panel's color dialog, if shown.
Add a "response" signal to GimpColorPanel, which is emitted upon
color dialog response.
In both cases, the response is a GimpColorDialogState, which should
be either GIMP_COLOR_DIALOG_OK or GIMP_COLOR_DIALOG_CANCEL, and not
an actual dialog response id.
Better factorize by reusing code rather than recreating a combo box
which does basically the same thing. I only added a boolean parameter to
retrieve only the sublist of manual language.
It also takes advantage of the self-translated language names from
initialization.
When the manual in your current language is not installed, yet other
manuals are available, the help dialog will now propose either to read
the manual online (as was already the case) or to select a manual in
another language instead. This is even more important since we don't
have as many manuals as localizations of GIMP. Therefore if one took the
explicit step to install a manual in another language, it makes sense
that means one may know the alternative language. As an example, we have
3 Chinese localizations (zh_CN|TW|HK) but only a zh_CN manual. I could
definitely imagine someone with a zh_HK GUI to go for the zh_CN manual
as a fallback. Or other languages even, whatever!
This is a first step. Right now once one chose the alternative help
language, it is not possible to reset it yet (except by editing
"help-locales" in gimprc). The next step will be to add the settings in
Help System preferences.
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
this commit changes just those which make no difference to
functionality: property and object member defaults that get overridden
anyway, return values of g_return_val_if_fail(), some other stuff.
Add "gboolean with_filters" to gimp_drawable_calculate_histogram(),
which is passed as FALSE in almost all places, except the histogram
dockable where we want to see both the drawable's unmodified histogram
*and* the histogram after filters are applied.
- trailing whitespaces cleaned out;
- vectors are called "path" in all visible strings;
- do not check for floating selection and active channel: oppositely to
layers, a vector can be selected in the same time as a channel, and
while there is a floating selection.
More than 2000 lines of code less in app/, instead of
if (instance->member)
{
g_object_unref/g_free/g_whatever (instance->member);
instance->member = NULL;
}
we now simply use
g_clear_object/pointer (&instance->member);
Don't offset the ui range of op properties that use pixel-distance
units to the top-left corner of the region, since they're relative;
only do that for pixel-coordinate units. Let their ui range be
[0, width/height].
Pass a "GimpCreateControllerFunc" to all gimppropgui-*.[ch]
constructors which takes a callback (to update the config object when
the on-canvas GUI) and a controller type that determines the
callback's signature, and returns another callback (to update the
on-canvas GUI when the config object changes).
In GimpOperationTool, pass such a GimpCreateControllerFunc that
handles creating and adding on-canvas controller via the new
gimpfiltertool-widgets.[ch]. So far, a simple line like in the
blend tool is supported.
Add a custom GUI for gegl:spiral, and have its origin, radius and
angle controlled by such a line.
Thanks to Lionel N. who bugged me with his Windows installation where
the XML file was not found by GIMP. We should output a warning when this
happens so that packagers can detect the issue and the expected
installation path for this dependency.
The reporter wants me to call him "Padawan Lionel" but I won't fall for
it! Or did I? :-D
This way, you can increment repeated messages even when not the last
one and you don't overflow the error dialog needelessly when 2 errors
repeat one after another.
by encoding them directly in the string attached to all filter
actions. The code now supports both "gegl:some-operation" and
"gegl:some-operation\n<serialized config>".
Add "default_settings" to GimpGeglProcedure to store the settings of
the invoking action, much like the "default_run_mode" member.
Change filters-commands.c to parse the new operation string, create
GimpGeglProcedures with the deserialized settings, and use those
settings when the procedures are ran.
Change the filter history to be smarter about what is already in the
history, there can now be several different procedures with the same
name.
Remove the dilate and erode actions from the drawable group, and add
them to filters, they are just special cases of value-propagate with
fixed settings.
so they show up in recent filters, and don't need their own callbacks.
This has the problem that they now show a GUI with no options, but
that simply puts on more pressure to fix this general uglyness of ops
without editable properties.
Commit 1e6acbd4e1 modified the
generated enum recipes to run gimp-mkenums from the source
directory, instead of the build directory, so that only the
basenames of the corresponding header files would appear in
the comment at the top of the generated files. This was a
mistake -- $(GIMP_MKENUMS) is expecting to be invoked from the
build directory.
Switch back to running gimp-mkenums from the build directory. To
avoid including the relative path from the build directory to the
source directory in the generated file, add a @basename@ production
variable to gimp-mkenums, which exapnds to the basename of the
input file, and use it instead of @filename@ in the recipes for the
generated enum files.
When regenerating an enum file, don't copy it back to the source
directory if it hasn't actually changed. This allows using a read-
only source directory where the enum header is newer than the
generated file, as long as they're not really out of sync.
OTOH, *do* touch the generated source-dir file even when unchanged,
in order to avoid re-running its recipe on the next build, however,
allow this to silently fail (which is harmless).
"layers-text-tool" action shows as "Text Tool" while "vectors-path-tool"
shows as "Path Tool". That's very confusing with tools-text and
tools-vectors respectively.
These actions are mostly about entering in edit mode with the active
layer or path. For text layers, it will enter text edition on canvas,
whereas just open the attributes edition dialog on other layers. For
consistency, layers-text-edit is renamed as well too layers-edit-text.
This also fix the side effect of commits 10099bd and 526918b where I
didn't realize that layers-text-tool was also working on non text layers
on purpose (being very badly named). Now there is a separate layers-edit
and layers-edit-text.
Thanks to Pat David for English corrections. :-)
Add support for The following GEGL op property keys, which shall
contain GUM expressions of the specified type, controlling the
corresponding UI attributes of the property's widget:
- sensitive [boolean]: controls widget sensitivity.
- visible [boolean]: controls widget visibility.
- label [string]: controls widget label (or the label of the
associated label widget).
- description [string]: controls widget tooltip text.
When any of above keys are present, the values they evaluate to take
precedence over the static values the corresponding attributes would
otherwise have.
GUM is a small DSL, used in some property keys of GEGL operations
to dynamically control UI attributes based on context. This commit
only adds an interpreter for the language; see the next commit for
the actual handling of the relevant keys.
See the comment at the top of gimppropgui-eval.c for a description
of the language.
Note that the interpreter is licensed under the LGPL.
We check them into git, so this makes it easier to keep them in
sync when using a separate build directory.
Case in point -- this commit also syncs a few enum files that went
out-of-sync with their headers.
Add a boolean 'pick_abyss' parameter to GimpCreatePickerFunc. When
this parameter is TRUE, the picker should pick outside the bounds
of the drawable. Use FALSE for color pickers, and TRUE for position
pickers.
and use them for the new image in "Paste as new image". We were using
the resolution and unit of the image the paste command was invoked
from, which is entirely random and useless.
Filters settings used to be serialized and deserialized only
when a filter tool's GUI was shown, too late for the code that
re-runs/re-shows filters with previous values.
Move the entire loading/saving code to gimp-operation-config.c, even
adding/removing the dummy separator item between timestamped automatic
history and manually saved settings. Load the settings automatically
when a settings container is requested, but still trigger saving from
the few places the container is changed in the GUI; could also
automate that later.
This commit also moves all settings of filters that have their own
tools from gimpdir/tool-options/ to gimpdir/filters/. Add compat code
to try the old filename if the new doesn't exist, so files are
migrated automatically.
WIP, but this step already fixes the bug.
Both in the GimpImage API and in the GUI. The toggle in the save
dialog now controls ZLIB compression directly. Changed the various
info labels accordingly. Ditch the XCF parasite that saved the XCF
compat mode.
Current code only guess resolution for a single monitor. Ideally
the widget sizes could be different depending on the window where a
given widget is on. But that's a start.
The function has been unused since commit b5cc2a9.
Its work is now divided into gimp_tool_palette_set_toolbox() and
gimp_tool_palette_hierarchy_changed().
Argh! Always triple-check commits before pushing!
Commit e30c92c had completely wrong big values, which I was using
to make tab border update really visible while testing.
Allow overriding icon sizes set in themes from the preferences.
This initial commit updates only toolbox icons. More to come.
4 options are available: small, medium, large and huge (the later would
likely be useful for HiDPI screens).
Uses a new widget GimpIconSizeScale.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
In particular, this enables grids whose points of intersection
are at the middle of the image's pixels, which is useful for
undistorted painting with odd-sized brushes using tools other than
the pencil.
This commit also changes the grid visibility behavior, so that the
the visibiltiy of horizontal and vertical grid lines (depending on
the zoom level) is independent.
Replace the 'with-behind' and 'with-replace' properties with a
single 'context' property, and use it to select the included
layer modes, according to their context mask.
Add a dummy GIMP_LAYER_MODE_SEPARATOR value to the GimpLayerMode
enum, and use it to explicitly mark the menu separators in the
layer-mode group arrays; add separators to the layer-mode menu
accordingly.
Update the rest of the code to use 'context' instead of 'with-behind'
and 'with-replace'. In particular, in the layers and layer options
dialogs, select the right context based on whether or not the
selected layer is a group.
Nobody has them anymore, and they are deprecated in GTK+ 3.x. This
also fixes all conflicting mnemonics except those I missed, but we can
fix them now.
and to operations/layer-modes/, respectively.
Add gimp_layer_modes_init() which asserts on the correct order of the
GimpLayerModeInfo array, and switch to accessing the array directly in
gimp_layer_mode_info().
Similar to the Photoshop mode of the same name. Assigns
either 0 or 1 to each of the channels, depending on whether the
sum of source and destination channel values is less than, or
greater than (or equals to), one, respectively.
This is equivalent to inverting the source, and using it to perform
per-pixel, per-channel threshold against the destination, which is
useful for various effects.
The colon-separated list used in the plugin originally comes from
gimp_help_get_locales() anyway. My previous code was using different
lists of locales in different places, which was inconsistent.
I know this looks absolutely horrible, please spare me comments about
that. This commit has the purpose to let everybody experiment with the
new modes, and suggest improvements of the GimpLayerModeBox widget; we
need *some* way of controlling the new layer mode madness.
These variations on darken only and lighten only have the advantage over the
componentvise versions that they always use the full triplet of either original
or new layer - meaning no new colors/hues will be introduced. This is similar
to how these modes operated/operates in picture publisher and photo-paint.
The print size displayed in image property and title format should use
gimp_unit_get_scaled_digits() instead of gimp_unit_get_digits() and
adding 1, which is quite random or magic number-y.
For operations needing to override default behavior sub-classes should still be
used.
This commit also enables pinligh, vividlight and linearlight blend mode modes
Ell