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
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
...regardless of image color precision
Split enum value GIMP_COLOR_FRAME_MODE_RGB into RGB_PERCENT and RGB_U8,
which display the current % values, and values in a range of 0..255.
Change GimpHistogram to take a "gboolean linear" parameter and always
honor that parameter, so both kinds of histograms can now be created
for all drawables.
Add a horrible "Linear" toggle to the histogram dockable which always
defaults to the active layer's actual pixel format, but can be
switched at any time. This UI is ugly and needs to change.
On the PDB, default to gamma-corrected if the plug-in is unaware of
higher precision, and to the drawable's native pixel format otherwise.
Other places using histograms (e.g. levels, curves) are unchanged.
The white, gray and dark sliders of GimpHandleBar have a black contour.
This makes the white and gray slider visible even with similar colored
background. On the other hand, the black slider is barely visible on a
dark background (and could even be made totally invisible using the same
color). So let's use a light-gray contour on the dark slider, making now
all sliders working with any background color.
These are used for display switching, and even though you could
remap these shortcuts, it would work only until you close an image,
open a new one, or reorder tabs in SWM, in which case your shortcut
would end up forcefully overrided, which is a bad user experience.
If we want to give more flexibility and allow one to map these
shortcuts, we must also make sure the display showing actions won't
override customized shortcuts. In the meantime, it is better to
simply forbid these in our preferences.
gtk_action_group_remove_action() removes the action from the group while
not actually cleaning any accelerator. This is a problem for transient
actions which have only a meaning within the current session, such as
the display switching actions named with the display ID (unique within
the session only).
Current commit, combined with the previous one (commit c0ee959), fix
"windows-display-*" actions being saved inside menurc.
Revert "app: action search should search accross all available actions."
This reverts commit 53b3673bd8.
Had to revert these two commits, quoting comment 6 of the bug:
Thinking again, that entire change is unfortunately wrong, the only
right UI manager is in fact
gimp_ui_managers_from_name ("<Image>")->data
because it's the global popup <Image> UI manager which is independent
of a display and it always in the right state for the currently
active image, all other UI managers are wrong.
Add GimpMenuFactory can always be found in a GimpDialogManager, use
gimp_dialog_factory_get_menu_factory() where we have a dialog factory
instead of accessing "global_menu_factory" or redundantly passing a
menu factory around where we already pass around a dialog factory.
<Dockable> has this whole list of actions named similarly to dialogs-*
actions, and we don't want these to take precedence, especially since
they would always create a new dock instead of just showing the existing
one if already present.
Also fix the redundancy check on already added actions.
Introduce virtual function GimpViewable::is_name_editable() and class
member "gboolean name_editable" for the default value. Default to
FALSE and only return TRUE if the name can actually be edited by the
user.
When attemting an edit, check the new API and beep instead of starting
the edit.
We handle multi-selection by letting GtkTreeView handle button press
when the widget is in GTK_SELECTION_MULTIPLE mode. Change that code to
only do that when one of the participating modifiers (shift and
control on Linux and Windows, shift and cmd on macOS) is pressed.
This makes sure that the same thing is not randomly handled by two
different pieces of code, and probably fixes bug #738440, tho I can't
be sure.
In the "New Image" and "Convert Precision" dialogs. The "Gamma/Linear"
switches get adjusted automatically to the new defaults, but can be
changed manually.
The code was still checking for "plug-in-recent-*". Also, rename the
actions to "filters-recent-*" instead of "filter-recent-*" for
consistency with the other filters actions.
Add property "color-tag" of type enum GimpColorTag to GimpItem so all
layers, channels and paths can be tagged with a color.
For interoperability, use the color list from Krita which is a
superset of Photoshop's colors.
Features a "Color Tag" submenu in the layers, channels and paths
menus, a row of color radio buttons in the properties dialogs,
undo and PDB API.
As a side effect, some common code is now factores out into
items-actions.[ch] and items-commands.[ch] which adds visible, linked
and lock actions for layers and channels.
Convert GimpRGB to CMYK using a color transform to the configured CMYK
profile instead of the naive gimp_rgb_to_cmyk().
Add gimp_color_frame_set_color_config() and call it on all color
frames in the GUI (color picker tool, cursor info, sample point view).
Keep a GimpColorTransform around that does the conversion.
Also color manages the frame's color area now (visible in the sample
point view), which was forgotten earlier. Addresses bug #467930.
Fix the check that keeps events on overlay widgets from entering the
tool event mechanism, they have no business there.
gimp_overlay_child_realize(): set the embedding widget's event mask on
all overlay children, so their windows will be used as event window,
so their events become distinguishable from events on the parent (the
canvas).
gimp_display_shell_canvas_tool_events(): fix the check for events on
overlays, and skip them for real this time.
Have "Save" and "Restore" buttons in both the tool preset list/grid
and the tool preset editor. The save button stores the active tool's
options in the preset, if possible.
Add new setting GimpGuiConfig:devices-share-tool. When TRUE, we never
copy any properties between the user context and the GimpDeviceInfo's
context, so no tool or anything changes.
We do however still keep track of the active device so the setting can
be enabled/disabled at any time. Also hide GimpDeviceStatus' tool,
brush etc. indicators in "shared" mode.
Add GimpCellRendererButton and use it to add a "Save" icon to each row
of dirty images. Click invokes the "edit-save" action, shift-click
invokes "edit-save-as". Also add a tooltip for the icon button.
Involves minor changes to GimpContainerTreeView to allow
GimpCellRendererButton to be added, and to allow external
"query-tooltip" handlers to run.
and use gimp_file_new_for_config_path() and _get_config_path() when
dealing with them. We used a weird mix of config paths and plain
(filesystem encoded) paths, waiting to to break on umlauts or
whatever. The code in gimpcolorconfig.c was particularly bad.
Add a SELECT_SOFTPROOF_PROFILE mode to the color profile dialog and
use it to select a profile from a newly added "Soft-Proofing Profile..."
menu item in view -> color management.
...after entering single window mode
In GimpToolPalette, implement GtkWidget::hierarchy_changed() and
re-set the tooltips using the new toplevel's actions.
In gimp_widget_set_accel_help(), make sure we don't connect to the
same action twice, and make sure we disconnect everything if either
the widget or the accel_group go away.
It's deprecated in GTK+ 3.x, so we get rid of some deprecation
warnings. Also, it has always only been a utility function that hides
what is really going on in the widget hierarchy.
Try harder to show help when webkit is missing or the help browser
won't start:
- offer to switch to the web browser when the help browser is
present, but won't start for some reason
- in prefs, don't bother showing the help browser GUI when webkit
is missing, otherwise show a warning label if the help browser
is not installed even though webkit is there. Switch to the web
browser in both cases (modified patch from lisanet)
- add OS X replacement for gtk_show_uri() in plug-in-web-browser
(modified patch from lisanet)
(gimp-2.9:3): Gimp-Core-CRITICAL **: gimp_marshal_VOID__OBJECT_POINTER: assertion 'n_param_values == 3' failed
Conflict between signal marshal function
and signal emission.
AddressSanitizer output (paths manually shortened)
Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7f543247d1d0 in realloc (/lib64/libasan.so.3+0xc71d0)
#1 0x7f542d3ad02f in g_realloc glib/glib/gmem.c:159
#2 0x57918d in gimp_color_history_set_property gimp/app/widgets/gimpcolorhistory.c:169
#3 0x7f542d681ec0 in object_set_property glib/gobject/gobject.c:1423
#4 0x7f542d681ec0 in g_object_new_internal glib/gobject/gobject.c:1817
#5 0x7f542d6839ed in g_object_new_valist glib/gobject/gobject.c:2042
#6 0x7f542d683c73 in g_object_new glib/gobject/gobject.c:1626
... standard icon names and GTK+ icon names as second choice.
We should only use GIMP specific icon names as last resort, when there
is no standard or GTK+ names dedicated to the function.
This is made possible thanks to commit 3cc77b0.
s/gimp-document-recent/document-open-recent/
s/gimp-indent/format-indent-more/
s/gimp-next/go-next/
s/gimp-previous/go-previous/
s/gimp-save/document-save/
s/gimp-save-as/document-save-as/
s/gimp-revert/document-revert/
s/gimp-open/document-open/
s/gimp-document-recent/document-open-recent/
s/gimp-quit/window-close/ ou s/gimp-quit/application-exit/
s/gimp-warning/dialog-warning/
s/gimp-edit-clear/edit-clear/
s/gimp-justify-.*/gtk-justify-.*/
s/gimp-font/gtk-select-font/
s/gimp-color-palette/gtk-select-color/
s/gimp-cancel/gtk-cancel/
Add gimp_prefs_box_set_page_scrollable() which does what it says, and
make the tallest pages of the prefs dialog scrollable. This method
allows the dialog's smaller pages to still enforce a minimum height
for the window.
Quite heavily modified by Mitch to address the more general issues
mentioned in comment 35 of the bug:
- Remember the added mask's type and the invert boolean in
GimpDialogConfig
- Add new prefs page "Dialog Defaults" which will contain
only stuff from GimpDialogConfig and can be reset separately
- Remove static mask variables from layers-commands.c and
use the new config values for both interactive mask adding
with the dialog, and for the shortcut based method
- Add a button to the layers dialog which supports add, add
with last values, delete, apply
- Add modifier-click shortcuts on the layer preview with the
same modifiers as on the button
... starting with toolbox buttons.
This is particularly a problem in single window mode (and sometimes in
multi-window mode) where canvas easily loses focus, hence key events.
...after entering single window mode
This commit fixes dangling pointers in GimpDockColumns, it doesn't fix
the bug but it's a prerequisite. Original patch by Massimo.
Don't remove the GDK_KEY_space in GimpSearchPopup because that's
impossible and removes it from the entire GimpPopup class. Instead,
don't handle the "space -> confirm" binding manually if the focus
widget is a text widget.
Pass a GeglRectangle to all gimp_prop_gui_*() functions, and set
the soft limits to the rectangle's extents if the GParamSpec
metadata's "unit" is "pixel-coordinate" or "pixel-distance".
In GimpSymmetryEditor, pass the image extents, in GimpOperationTool
pass the drawable extents.
Mitch gets a better idea to deal with soft limits (i.e. min/max values
different from the property min/max) applied to a spin scale created by
gimp_prop_spin_scale_new().
So let's just remove the current implementation (using locale data on
the GimpConfig object). The symmetry spin scales are back with crazy
huge maximums, which makes quite a horrible GUI, but this is only
temporary until Mitch commits his new implementation.
Add an icon button to the dynamics editor's "mapping matrix" page. It
looks just as ugly as the icon button of the tool preset editor, the
two should be visually improved together.
Currently a GimpSpinScale created with gimp_prop_spin_scale_new() will
use the associated property's lower and upper values.
Unfortunately these generic values may not be always relevant and we
may want to construct a spin scale UI adapted to the current image.
For instance, several symmetry painting have a x/y property which has
to stay within the image's dimension, but changing the property's lower
and upper values would affect the symmetry on the class level (i.e. for
all similar symmetries on all images).
Let's allow setting data on object with key "property-name:min|max" to
provide locale min/max values specifically for this object.
This is used only on the symmetry dock for now, but could be used as
well on GEGL op UIs.
and update their color transforms with the new monitor's color
profile. A widget is considered changing monitors when its toplevel
window's center crosses, in order to let widgets within one window
have consistent colors.
In particular, I don't want the preedit foreground colors to be
displayed in the text style editor UI. They are only temporary hints
and should not be taken into account as user-chosen style.
There is nothing in our UI to set background color to text, but this
can be used internally, for instance to display input method's preedit
texts with specific colors.
Automatically connect to the global GimpColorConfig unless a different
one is set manually (like for previews that belong to a
GimpDisplayShell and should follow its color management settings. Add
public API for subclasses to get to the renderer's color
transform. Automatically color manage rendered pixbufs, just as we
already manage temp_bufs.
which encapsulates a cmsHTRANSFORM and does all the pixel format
conversion magic. It has API to create transforms and proofing
transforms, and to convert pixels arrays and GeglBuffers.
Before, each place which has a transform had to keep around the
transform and its input and output Babl formats, and had to implement
lots of stuff itself. Now all that lives in GimpColorTransform,
removing lots of logic from many places, and pretty much removing lcms
from the public API entirely.
This removes including <lcms2.h>, LCMS_LIBS and LCMS_CFLAGS from
almost all directories and potentially allows to replace lcms by
something else.
They are unreliable because every type checking cast discards them,
they are useless anyway, visual clutter, added inconsistently, and
generally suck. Wanted to do this a long time ago, it was a bad idea
in the first place.
Instead, store only the action's name, and look it up upon searching.
Keeping a reference to the actions in the history extended the lifetime of
actions that sohuld have otherwise died, leading to all sorts of nastiness. In
particular, the Alt+[n] actions to switch between images would remain bound to
their accelerator after the image has been closed, holding a dangling display
pointer, which would lead to a segfault, or fail with a CRITICAL message, when
using the accelerator again.
... when the button is clicked
Previously, the old color retained its previous value, so when the color
selection dialog was canceled, the button's color would go back to a
potentially outdated value, instead of the color it had when it was
clicked (for continuously-updated color buttons, at least.)
Add a View -> Color Management submenu that allows to change
the color management mode per-display.
Internally, keep a GimpColorConfig object around per-display that
is synchronized with the global config except for the properties
that have a per-display GUI (currently the mode).
Also provide an "As in Preferences" menu item to follow the global
settings again.
Add "gboolean color_managed" and "GFile *color_profile" to
GimpTemplate. Add a toggle and profile combo to GimpTemplateEditor.
Honor the new template properties in gimp_image_new_from_template().
Using a GFile property instead of a GIMP_TYPE_CONFIG_PATH is
preliminary, see the previous commit. I'd like to use GFile more
directly when dealing with config files, this is for testing that.
This fixes a problem where in some cases the item next to the edited
item was changed inadvertently. This was caused by the fact that
the change of the label within the tree_name_edited callback triggered
a re-ordering of the items, which triggered a stop editing signal, which
finally caused a re-entrance in the tree_name_edited callback. By this
time the item below "path_str" has changed, which caused the name of
another object to be edited.
