Build for macOS on CI breaks with:
> ../gimp3-2.99.19/libgimpwidgets/gimppickbutton-quartz.c:210:45: error: use of undeclared identifier 'monitor_profile'
> space = gimp_color_profile_get_space (monitor_profile,
Resolves#11246
On Windows, a CRITICAL was being repeatedly thrown if you
didn't have a monitor profile set. This is because we were trying to
pass a NULL value to g_utf16_to_utf8 () whenever we needed to
convert a GeglColor.
This patch fixes it by checking if the monitor profile filename is NULL
before trying to convert it.
We dereference "file" twice in gimp_prop_file_chooser_button_callback(),
once in the GIMP_IS_PARAM_SPEC_CONFIG_PATH () condition and then
at the end of the function. This is likely due to a similar structure in 2.10,
which did not have a second condition.
As a result, any Gegl filter which had a file property would crash if set from
a GUI. The first g_object_unref() is removed so we only dereference "file"
once.
Resolves#11146
As Idriss Fekir and I noted, 5ce128a9 added support for
receiving GeglColor data to GimpColorAreas, but
retrieving it still resulted in RGBA application/x-color
values being stored when dragged.
This patch updates gimp_color_area_drag_data_get () to
give the format and profile information along with the
pixel values.
Mainly fixing GimpRGB comments and
parameters that are unused (or in unused
functions).
GimpCircle and GimpGradientChooser
have color conversions ported to use
GeglColor exclusively.
While the buffer used by Cairo may have a rowstride bigger than 3 * width, our
internally stored buffer has the exact size required for drawing the scale.
When changing the selected color, we have no reason to redraw the Z preview.
This preview should only be redrawn if the allocation size changed, or if we
change the previewed model or the Z component.
As for the XY preview, it should only be redrawn if the Z value is changed (and
of course, similarly, if the allocation changed or if model or Z component
changed).
No custom conversion code anymore. This also fixes some bugs in HSV when
I was wrongfully multiplying the hue by 360 when mixing babl and custom
code paths.
Until now we only had the case of the CMYK color selector using the
soft-proofing profile. Yet this is also interesting for other color
selectors, in particular to show out-of-gamut colors. Indeed if we
enable soft-proofing on the active image, it is interesting to show the
intersection of the current RGB/Grayscale space gamut with the
soft-proofing gamut.
Right now, this is only used in GimpColorSelect when showing colors in
LCh color space.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
- New libgimpcolor functions: gimp_color_parse_hex() and gimp_color_parse_name().
- GimpColorHexEntry is now space-invaded. Though recognized color names
and hexadecimal syntax are sRGB only (because CSS and SVG
specifications explicitly say that this syntax is for sRGB values), it
is possible to enter non-sRGB values with
gimp_color_hex_entry_set_color().
- GimpColorSelection is now space-invaded.
The invasion extended to some core widgets too, in particular GimpColorPanel (a
subclass of GimpColorButton). There was quite a lot of code depending on these
widgets.
This includes improvements on the out-of-gamut colored corner being shown for
unbounded component types out of the [0; 1] range (with some small margin of
error to avoid e.g. a -0.0000001 value to show as out-of-gamut).
There are still improvements to be made on the color rendering. In particular,
it still draws as CAIRO_FORMAT_RGB24 cairo surface. We should probably move to
draw as CAIRO_FORMAT_RGBA128F eventually (more precision and even allowing to
draw unbounded colors with a possible option, instead of always clipping).
Also adding the libgimpwidgets API gimp_widget_get_render_space().
- New function gimp_cairo_set_source_color() which is meant to replace
gimp_cairo_set_source_rgb(a?)() eventually. This new function sets the Cairo
source color, using the target monitor's profile of the widget where the Cairo
surface is meant to be drawn on. It also uses the color management settings
(such as whether a custom profile was set, instead of using system profile, or
also simply whether color management was disabled at all). It doesn't
soft-proof the color yet.
- Padding and out-of-gamut colors drawing now use the new
gimp_cairo_set_source_color(). These don't need any soft-proofing anyway.
- Out-of-gamut color property in GimpColorConfig is now a GeglColor property.
We pass 2 GeglColor through the wire now. Since it is passed very early
(when sharing the configuration), I had some issues with initialization
order of GEGL, and in particular when calling gegl_init() before
gegl_config() inside _gimp_config(), I had a bunch of such criticals:
> Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core'
Anyway in the end, I store the passed colors as raw bytes and strings in
the GPConfig object, and re-construct the GeglColor last minute in
_gimp_config().
- app: gimp_context_get_(foreground|background)() are now returning a GeglColor.
- libgimp: PDB functions named similarly in libgimp are returning a newly
allocated GeglColor too.
- A few other PDB functions (the ones using these functions) were updated and
their signature changed to use GeglColor too, when relevant. Plug-ins which
use any of the changed libgimp functions were fixed.
- GimpContext: signals "(foreground|background)-changed" are now passing a
GeglColor.
- libgimpconfig: new macro GIMP_CONFIG_PROP_COLOR using gegl_param_spec_color().
- GimpContext: properties "foreground" and "background" are now GeglParamColor
properties.
- app: All code interacting with GimpContext objects were updated to receive a
GeglColor (that they may still convert, or no, to GimpRGB for now).
- app: gimp_prop_gegl_color_button_new() was added as an alternative to
gimp_prop_color_button_new() when the property is a GeglParamColor. Eventually
the former should replace completely the latter.
- libgimpwidgets: gimp_prop_color_area_new() now works on GeglParamColor
properties only.
- libgimp: gimp_procedure_dialog_get_widget() will generate a GimpColorArea for
GeglTypeParamColor arguments.
Without this, when creating the new config folder for the first time
(update from 2.10 to 2.99/3.0), if say "Legacy" icon theme was set, it
would not show on the first run, though it would show on the second run.
Now it shows directly on the first run.
The merged icon theme is simply named "Default" and contains a color and
symbolic variant for all icons. While in 2.10, it made sense to have both icon
themes because a theme had no concept of a "symbolic" variant back then, icon
themes in 3.0 have this concept and we support this in GIMP through the "Use
symbolic icons if available" option in Preferences.
Until now, it was confusing to have both themes + this option, even more as you
could use the Color icons with the "Use symbolic icons" option, which meant that
if some icons were missing, you could end up with a mix of color and symbolic
icons (and oppositely using the Symbolic theme with the option unchecked).
The new state is much simpler and less confusing. Just 1 icon theme with both
color and symbolic variants (the latter being used by default).
Note that the identical meson.build in each size subfolder is still mandatory
because of the inability of meson (still!) to generate files with
custom_target() in a subfolder as output.
MINGW64
- uses 0x601 as value for _WIN32_WINNT. No need for us to define
it to that value or even lower values in some places.
This also gets rid of: warning: "_WIN32_WINNT" redefined
- has 0x0502 for WINVER, so get rid of us setting it to 0x0500 in
gimp-app-test-utils.h. It also seems that the need to use G_OS_WIN32
has disappeared here.
- DIRECTINPUT_VERSION is 0x0800, no need for us to set it to that value.
- AI_ADDRCONFIG was apparently missing from the MINGW headers in the
past, but not anymore.
This fixes this warning (as appeared with commit ad8b47bff7):
[1/235] Compiling C object libgimpwidgets/libgimpwidgets-3.0.so.0.9900.17.p/gimpdialog.c.o
../../../../../../../dev/src/gimp/libgimpwidgets/gimpdialog.c:774:1: warning: ‘gimp_dialog_set_title_bar_theme’ defined but not used [-Wunused-function]
774 | gimp_dialog_set_title_bar_theme (GtkWidget *dialog)
We could either put the whole `gimp_dialog_set_title_bar_theme()` declaration,
definition and usage into #ifdef, or only the implementation (making the
function a no-op on non-Windows platforms). I chose the former. There was some
discussion that maybe some implementation may happen later for other platforms,
but until then, no need to call it needlessly (even more as we don't know when
any theoretical other implementation would happen).
On Windows, the title bar can be set to light or dark mode via DwmSetWindowAttribute ().
This adds code to update the main title bar and dialogue title bars based on the current theme.
The main title bar uses "prefer-dark-theme", while the dialogue title bars
uses the color of the widget background to assume the correct color.
The various drawing APIs are cumulative which is not right when we want to
change a preview (especially if the preview changes dimensions! Then we end up
with pieces of the previous drawing behind the new one).
This new function will allow to reset the whole drawing. Note that we may end up
with some black background if the preview are doesn't have the right dimensions.
This should be improved later too.
- Move the property widget functions for GimpResource properties into a new
libgimp/gimppropwidgets.[ch] file. This mirrors the files
libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types.
- Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new().
- gimp_prop_chooser_factory() doesn't need to be public.
- Add a label to GimpResourceSelectButton, make so that the
gimp_prop_chooser_*_new() functions set the property nick to this label and
add this label to the size group in GimpProcedureDialog.
Instead of passing a guint32, pass the proper type, since our the HANDLE type
can be 64-bit on Windows (according to links I found).
I was hoping it might be the reason for the breakage under Windows, though I
also found Microsoft documentation saying that the 64-bit handle can be safely
truncated: https://learn.microsoft.com/en-us/windows/win32/winprog64/interprocess-communication?redirectedfrom=MSDN
Nevertheless I'd appreciate testing again from NikcDC or anyone else, as I
reactivated setting transient between processes on Windows.
Note that I also pass the proper types on X11 now (Window), even though guint32
worked fine. Better be thorough.
Having windows ID as guint32 is a mistake. Different systems have
different protocols. In Wayland in particular, Windows handles are
exchanged as strings. What this commit does is the following:
In core:
- get_window_id() virtual function in core GimpProgress is changed to
return a GBytes, as a generic "data" to represent a window differently
on different systems.
- All implementations of get_window_id() in various classes implementing
this interface are updated accordingly:
* GimpSubProgress
* GimpDisplay returns the handle of its shell.
* GimpDisplayShell now creates its window handle at construction with
libgimpwidget's gimp_widget_set_native_handle() and simply return
this handle every time it's requested.
* GimpFileDialog also creates its window handle at construction with
gimp_widget_set_native_handle().
- gimp_window_set_transient_for() in core is changed to take a
GimpProgress as argument (instead of a guint32 ID), requests and
process the ID itself, according to the running platform. In
particular, the following were improved:
* Unlike old code, it will work even if the window is not visible yet.
In such a case, the function simply adds a signal handler to set
transient at mapping. It makes it easier to use it at construction
in a reliable way.
* It now works for Wayland too, additionally to X11.
- GimpPdbProgress now exchanges a GBytes too with the command
GIMP_PROGRESS_COMMAND_GET_WINDOW.
- display_get_window_id() in gimp-gui.h also returns a GBytes now.
PDB/libgimp:
- gimp_display_get_window_handle() and gimp_progress_get_window_handle()
now return a GBytes to represent a window handle in an opaque way
(depending on the running platform).
In libgimp:
- GimpProgress's get_window() virtual function changed to return a
GBytes and renamed get_window_handle().
- In particular GimpProgressBar is the only implementation of
get_window_handle(). It creates its handle at object construction with
libgimpwidget's gimp_widget_set_native_handle() and the virtual
method's implementation simply returns the GBytes.
In libgimpUi:
- gimp_ui_get_display_window() and gimp_ui_get_progress_window() were
removed. We should not assume anymore that it is possible to create a
GdkWindow to be used. For instance this is not possible with Wayland
which has its own way to set a window transient with a string handle.
- gimp_window_set_transient_for_display() and
gimp_window_set_transient() now use an internal implementation similar
to core gimp_window_set_transient_for(), with the same improvements
(works even at construction when the window is not visible yet + works
for Wayland too).
In libgimpwidgets:
- New gimp_widget_set_native_handle() is a helper function used both in
core and libgimp* libraries for widgets which we want to be usable as
possible parents. It takes care of getting the relevant window handle
(depending on the running platform) and stores it in a given pointer,
either immediately or after a callback once the widget is mapped. So
it can be used at construction. Also it sets a handle for X11 or
Wayland.
In plug-ins:
- Screenshot uses the new gimp_progress_get_window_handle() directly now
in its X11 code path and creates out of it a GdkWindows itself with
gdk_x11_window_foreign_new_for_display().
Our inter-process transient implementation only worked for X11, and with
this commit, it works for Wayland too.
There is code for Windows but it is currently disabled as it apparently
hangs (there is a comment in-code which links to this old report:
https://bugzilla.gnome.org/show_bug.cgi?id=359538). NikcDC tested
yesterday with re-enabling the code and said they experienced a freeze.
;-(
Finally there is no infrastructure yet to make this work on macOS and
apparently there is no implementation of window handle in GDK for macOS
that I could find. I'm not sure if macOS doesn't have this concept of
setting transient on another processus's window or GDK is simply lacking
the implementation.
This is used in the generated GUIs for GimpChoice arguments, but also for
validation of property setting.
New functions:
* gimp_choice_set_sensitive()
* gimp_string_combo_box_set_sensitivity()
These will replace the int arguments used in place of enums. The problem of int
arguments used as list of choices is that it makes calling PDB functions very
opaque. This is especially bad when a list is long, so you constantly have to
refer to the documentation to understand what a series of numbers mean in
argument lists.
And the second issue is that plug-in developers have to manually maintain a list
of values both in the GUI and in the documentation string. This help text may
get out-of-sync, may end up with missing values or whatnot. Also if it is used
as tooltips, it makes for very weird tooltips in the graphical interface, with
an overlong technical list of int-values mapping which should ideally only be
made visible in the PDB procedure browser listing.
- GimpLabelStringWidget widget makes any widget with a "value" string property
into a GimpLabeled.
- Add a "value" string property to GimpStringComboBox (which makes it usable by
GimpLabelStringWidget).
The assert tests were not taking well into account the case where upper == lower
or where it's an integer spin which is just separated by 1 (both cases seem
silly, but it makes sense in the case of generic — or even dynamic! — spin
widgets where we want to adjust the min and max, e.g. depending on the property
of the image, or on other settings.
We use US English which uses behavior. So we replace all occurrences of
behaviour.
Most notable is File Open behavior in preferences. Besides that several
mentions in function documentation and a few in comments.
In commit 48c27770 some unicode related changes were made. As a result of
that on Windows display_device, which was previously a duplicated string,
is now referenced directly.
However, the g_free was not removed, causing a crash.
We resolve this by removing the obsolete g_free.
… to long format of unit names.
We can clearly see that the main part of the widget is correctly resized but not
the popup. Unfortunately we don't have access to the popup widget which is
private data, so the best workaround I found so far was to pop the menu down and
up, which basically provokes a redraw to the correct size after contents change.
This fixes MR !385.
Adds a check to cast resolution to an int if units are pixels,
rather than calling gimp_unit_get_scaled_digits().
This prevents a LibGimp-CRITICAL about "_gimp_unit_cache_get_digits:
assertion 'unit >= GIMP_UNIT_INCH' failed"
getting rid of using the the deprecated pointer grab API.
Since there is something fishy and gtk_get_event_widget(event) always
returns the GtkInvisible we grab on (not the actual event widget), we
just steal the "find widget at pointer" code from gtkinspector and
find the help widget that way.
In case someone passes a `GtkWidget` rather than a `GtkWindow` as a
parent to a `GimpDialog`, we still have another way of trying to get its
parent window, using `gtk_window_get_toplevel()`. If we still get a
window from that, it allows us to still specify a reasonable
"transient-for" value for our newly-made `GimpDialog`.
Per @Jehan, this solution would prevent default icons from being loaded
in custom themes if they did not include their own version.
The only thing kept from !909 is the replacement of hardcoded strings
in a few files with constants defined in gimpicons.h.
Five icons in the Layer dockable were being replaced by GTK defaults at
runtime. A "gimp-" prefix was added so that GIMP's version would always
be used. A few dialogues were fixed to use constants rather than
hardcoding the filename, to make it easier to update the icon in the
future.
GimpFrame has a property 'line-spacing'. gimp_frame_get_label_spacing ()
tried to access it as 'line_spacing', so it always returned 0.
Fixing the typo should now return the true spacing value.
These were the last use of the old GtkAction API and it was particularly
annoying here as this widget is used both in core GIMP and in plug-ins, yet core
GIMP actions were not GtkAction anymore (so the "activate" signal handler's
signature was different, which would crash the core code).
Now the clash is resolved as this widget just uses GAction (which both
GimpAction, for core code, or GSimpleAction, for plug-ins, are).
This is also the absolute last use of GtkAction (and other related API) in all
our code (core, libgimp* and plug-ins). \o/
In such a case, we may not want to connect to "query-tooltip", yet we still want
the normal tooltip to show up. This was a case for instance for the recently
opened file actions ("file-open-recent-*") or opened image actions which were
not showing their tooltips.
The tooltip contains the reason for action inactivity, if relevant. And in case
of a GtkMenuItem in particular, it will also contain the "Press F1 for more
help" text at the bottom.
RGB 0..255/0..100 and LCh/HSV settings are now remembered when closing
and reopening GIMP.
A few enums were explicitly cast to GimpColorSelectorChannel to clear
some compiler warnings.
There was one case in Inkscape which we could not do: distributing objects
keeping even gaps between them. Until now, we could only distribute keeping even
distance between anchor points (top, left, bottom, right or center).
With these 2 additional distribute options, I believe that GIMP is able to do
all the Alignment and Distribution options available in Inkscape (not the
"Rearrange" or node features, neither the text align/distrib; I just mean the
common align/distribute on objects), and even a bit more thanks to the anchor
point system (e.g. in Inkscape, we can't left or right-align to a reference
object/image center, or we can't center to a reference left/right/bottom/top
border; but we can do it in GIMP).
The icons are hopefully temporary, until we can make better ones.
Just "help" is not one of the standard icon names as per the Freedesktop Icon
Naming specification.
See: https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
Therefore when using this name, we usually don't have any icon (especially as we
don't provide any in our own icon themes).
Use "system-help" instead which is a standard name 'for the “Help” system
category'.
Automake doesn't accept the "if else" syntax. Instead, we must add a new if/else
inside the first else block.
While I'm at it, I also add a G_GNUC_INTERNAL to the internal function
_gimp_pick_button_win32_pick(), though I don't think it's absolutely necessary
(yet explicit is better).
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
Actually our X11 implementation is right, and the implementation from
the Freedesktop portal is "as far as it can do", i.e. that we get the
returned RGB value, which is unfortunately in display space. And it
doesn't return any space information together (we don't even know which
display the color comes from, in multi-display setups).
Therefore let's check if we are running GIMP on X11 and if so, let's
call this implementation first.
See this report on xdg-desktop-portal to get proper space info:
https://github.com/flatpak/xdg-desktop-portal/issues/862
This adds a Soft-Proofing pop-over menu when right-clicking the toggle
in GimpStatusBar. It lets users toggle proofing, using BPC and showing
out-of-gamut colors. It also lets users change the profile and
rendering intent.
Adds a simulation_bpc and simulation_intent to GimpImage to allow
plug-ins to access it
for CMYK import/export.
Four pdb functions were added to enable this access:
image_get_simulation_bpc (), image_set_simulation_bpc (),
image_get_simulation_intent (), and image_set_simulation_intent ().
Next, it updates menu options and code to support GimpImage's
internal simulation intent and bpc.
New 'simulation-intent-changed' and 'simulation-bpc-changed signal
are emitted via
GimpColorManagedInterface so that relevant tools
(such as the
CYMK color picker, GimpColorFrame, and future pop-overs)
are aware of these changes.
Generated *enums.c now have an additional stamp no-op header include
(see last 2 commits). Sync this change into the autotools generation
scripts to prevent back and forth useless generation of these files each
time we switch from one build system to another.
They are nearly the same as initially, except that now they include an
intermediate stamp header which will be generated by the build system.
The only 2 enums which don't need these includes (and are not versioned)
are libgimp/gimpenums.c and libgimpthumb/gimpthumb-enums.c.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
This explains why the defcheck script never complained for the 2
*_get_resource() functions removed in my previous commit. These were
exported in the libgimpwidgets library on the autotools build (and not
on the meson build).
Fix the discrepancy by not exporting these symbols on autotools as well,
as I don't think this is needed on public API.
This should now fix the distcheck build for autotools.
The defcheck.py file finds these errors:
> Problem found in /home/jehan/dev/src/gimp/libgimpwidgets/gimpwidgets.def
> the following symbols are listed in the .def-file,
> but are not exported by the library.
> - gimp_color_picker_cursors_get_resource
> - gimp_icon_pixbufs_get_resource
Indeed these don't exist. Unsure why the autootols check failed to
report these until today.
gimp_color_config_get_simulation_color_profile() is returning a new
object, so we had 2 code paths giving either allocated data or not.
Therefore simply ref the passed softproof profile in the second code
path, and don't ref it anymore when caching it (especially as it might
also be NULL at that point).
This removes rate limiting of ruler and statusbar updates which were
required to get acceptable performance on mac for drawing on the canvas.
This requires the latest changes on in Gtk 3.24 to be incorporated.
Adds a simulation_profile to GimpImage to allow plug-ins to access it
for CMYK import/export.
Two pdb functions were added to enable this access:
image_get_simulation_profile () and image_set_simulation_profile()
Next, it updates menu options and code to support GimpImage's
internal simulation profile. Menu items are moved from View to Image's
Color Management section.
New 'simulation-profile-changed' signal is emitted via
GimpColorManagedInterface so that relevant tools (such as the
CYMK color picker, GimpColorFrame, and future dockable
dialogue) are aware of these changes.
… GimpIntStore for value filling.
GimpIntComboBox was not taking ownership of the value store whereas the
newer GimpIntRadioFrame was taking ownership. As a more common practice,
I decided to leave ownership to the caller (which will therefore have
the responsibility to free the data) in the main class and property
widget APIs.
On the other hand, let's steal ownership of the store objects in the
gimp_procedure_dialog_get_int_*() functions as these are really used for
very quick and easy creation of dialogs by script writers. It would even
allow to create a GimpIntStore inline within the widget creation
function, if one wanted to.
… GimpProcedureDialog.
- gimp_prop_file_chooser_button_new() now works also with properties
G_PARAM_SPEC_OBJECT having a value_type == G_TYPE_FILE (additionally
to GIMP_PARAM_SPEC_CONFIG_PATH properties).
- gimp_procedure_dialog_get_widget() will now create a
GtkFileChooserButton in open mode for such a GFile property.
- New gimp_procedure_dialog_get_file_chooser() API to create
GtkFileChooserButton for GFile properties in other modes.
Current limitation: GtkFileChooserButton doesn't have a label. This
should be fixed, probably by creating another custom widget with would
be a labelized file chooser button.
A proper class for a frame containing radio buttons. This object has a
"value" property and will therefore be very easy to use in various API
binding a config property to a widget property.
A GimpIntRadioFrame is also what gimp_prop_int_radio_frame_new() will
return now.
gimp_prop_int_radio_box_new() on the other hand is being removed. It is
used nowhere and is unneeded. If someone really needs a non-labelled
group of radio buttons, they can also create a GimpIntRadioFrame, remove
the label and hide the borders. At least they will still be able to
easily bind it to a config property.
- Some coding style fixes (alignment, etc.).
- Adding missing "Since: 3.0" annotations. We are still wondering
whether this should go in 2.10, in which case, it would become
"Since: 2.10.32" annotations. See discussion in !274.
- Changing gimp_checks_get_colors() signature: merge the 4 color
arguments into 2 (inout) arguments which seems a bit nicer in C,
whereas binding handles such arguments correctly. The other
alternative would have been to at least change the order to have out
arguments in the end.
I also hesitated to get another API in libgimp, which would have been
config-aware (just returning the 2 check colors, depending on user-set
Preferences), then having GimpPreviewArea handling 2 colors (without a
GimpCheckType input). But actually, doing this, we'd remove the nice
menu popup where one could choose a generic check type (not everyone
wants to play with specific non-gray colors) in Gimp*Preview widgets.
So in the end, I left this whole thing as-is.
Instead I document the function with code sample to initialize
properly the GimpPreviewArea (since libgimpwidgets/ are independent
with no knowledge of the core config) in order to respect user
preferences.
- Hide the color properties in gimp_preview_area_menu_new() because
anyway gimp_preview_area_menu_new() does not support GimpRGB
properties right now (so all we get are warnings). It's still possible
to select custom colors on GimpPreviewArea, simply we are stuck at the
ones set in Preferences globally for now (unless a plug-in creates
custom GUI to set these).
Fixed Conflicts from !274:
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
Reviewer (Jehan) note: cherry picked from MR !274. Still deciding
whether this will be pushed to gimp-2-10 branch too.
Fixed Conflicts from !274:
app/dialogs/preferences-dialog.c
app/display/gimpdisplayshell-draw.c
app/plug-in/gimppluginmanager-call.c
libgimp/gimp.c
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
libgimpwidgets/gimppreviewarea.h
libgimpwidgets/gimpscrolledpreview.c
Let's not try to align anymore the label text with the value (numbers
inside the GtkEntry) text. Our previous offset computation was wrong
anyway, but even correctly aligning the text, there could be cases where
the label's actual font was bigger than the number's font.
I had the case with GIMP set in Korean. The number text was 11-pixel
high but the Hangul text on 16 pixels in plug-ins using a GimpSpinScale,
most likely because the font used for numbers didn't have Hangul glyphs.
So we ended up with very ugly scale title on the bottom of the widget,
even out of the progress area. Instead, we just make sure that the label
is exactly in the vertical middle of the widget, disregarding the entry
layout's offset.
… blinking it.
This will be necessary to demo new features available only in some
situations. E.g. a new option in line art detection mode of bucket fill
would require said mode to be enabled.
The gimp_widget_set_identifier() doesn't really need to be there since
we don't install the gimpwidgets-private.h header. But I guess it makes
sense that we still need to add it for our internal use at least.
This should fix the CI.
I add it in libgimpwidgets because we need to also use it on propwidgets
created from there, but it's actually only for core GUI usage, so it's
actually in a private part of the library.
Though it's actually doing quite a basic thing, it is nicer and more
foolproof than a manual g_object_set*() everywhere. Moreover it will be
nicer to grep.
This function will help us raise attention to various widgets in
dockables by blinking them similarly to how we blink locks or visibility
icons.
I associate this with the fact that property widgets identifier will be
the property name, so we get identifiers for free when creating widgets
through the propwidgets API.
Gets drawing in the canvas speed on retina displays up to the speed
of FullHD displays on macOS, making 2.99 usable on macOS.
Generic change:
Changes the cursor_label to delay the drawing phase to the idle
queue, from immediate draw on all platforms.
Before the fix in 32049afd (using a deprecated function in Gtk3)
any draws on this label forced a full canvas redraw. This is due
to a quirk in how GtkLabel functions.
The redraw occurred because GtkLabels resize themselves and everything
around them by sending a resize message any time they receive new
text. These resizes then trigger the full canvas resize which triggers
a full canvas redraw that cannot be optimized by either Gtk or Big Sur.
MacOS changes:
Only redraws the cursor position label and each of the horizontal and
vertical rules (cursor tracking widgets) 3 times a second max for a
total of 9 redraws a second (ideally out of 60, though I don't believe
under any circumstances that GIMP achieves a 60fps).
Each of the cursor tracking widgets gets its own timeslice, and so
will not redraw when the other cursor tracking widgets are drawing.
This is required because Big Sur is merging all draw rects into
one large rect, dramatically slowing down draws.
This timeslicing ensures that draw rects are maintained at the smallest
possible size. So the typical redraw is a small rect around the
brush. However, 9 times a second, the rect will include one of the
3 cursor tracking widgets (rulers and cursor label).
Additionally, the code tries to minimize resizing the width of the
cursor label by checking if the widget is too small for the text,
then setting the char_width to a greater size so that resizes won't
be that common.
This improves the appearance of the widget as it no longer
constantly jumps about in size on each cursor move.
Here is a discussion of the issue:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/572#note_1389445
Reviewer's (Jehan) notes:
* The whole issue about GtkLabel resizing is no more after 32049afd. It
is normal for a widget to request a resize when needed. We just don't
want the statusbar to resize and triggering canvas redraws.
* Changing cursor position text into an idle function generally makes
sense.
Also it reverts commit 6de9ea7022 which had a bug I hadn't realized
when I accepted it: when we test for time, we don't know yet if it
will be the last position change, hence we could "refuse" the last
update. Therefore displayed cursor position would end up outdated
on macOS. This new implementation doesn't have the problem (the last
idle update always happens after the last move).
* The change about giving 1/3 timeslices to side canvas components
(rulers and statusbar) is a complete hack to work around the fact that
macOs doesn't report properly each damaged rectangle. Instead it
returns a huge bounding box. The workaround here is to expose these
area separately.
We have not been able to find a proper solution yet. This is the only
reason why I accept this code, for macOS only, to at least have
something usable there.
See discussions in MRs gimp!572 and gimp-macos-build!86. With these 2
MRs, Lukas reported GIMP 2.99 to perform even better than GIMP 2.10 on
Monterey, though it could not be tested on Big Sur unfortunately.
* Lastly the set_width_chars() thing is also an ugly hack which I will
try later to revisit (see !581). I only accepted it (with mandatory
macOS-only macro) to have an acceptable state for release after seeing
a screencast where the label size indeed "jumps around" on macOS.
… gimp_prop_widget_set_factor() to libgimpwidgets.
Now that GimpSpinScale is in libgimpwidgets, it's time to move the
associated prop too, to make it a prop widget with such a widget easily
creatable by plug-ins.
While doing so, I update both these functions logic, binding properties
together with the g_object_bind_property*() APIs (as we do already in
some other recent prop functions) rather than connecting to signals
ourselves. It makes for much simpler code.
I was initially considering a second widget, but it makes actually much
more sense to make the editability a property of the GimpLabelColor. It
also mean it can be switched on or off depending on situations.
I tried to have a not too overwhelming API, so we just ask for the label
and initial color at construction. We keep sane defaults for the rest
and let people tweak the result by getting the color area widgets
themselves (if they need to force-showing flat colors or change the drag
buttons in particular).
Another thing I wondered about was the initial size of the color area.
Without a size request or being in some container expanding its
children (which may also be ugly), it ends up too small. I can imagine
such widget being used especially when you want to display several
color rectangles next to each other with a label each. So I just set it
this way. Anyone is free to request a resize after constructing the
object.
Last but not least, the position of the label was especially of interest
here. For my idea of a list of colors, I could definitely imagine color
blocks aligned with vertically-oriented labels above or below. It might
be worth adding an API for this later on.
This would allow to enable, configure or disable drag ability of a
GimpColorArea ater its creation.
I tested that it works correctly in binding. For instance in Python:
> area.enable_drag(0)
> area.enable_drag(Gdk.ModifierType.BUTTON1_MASK |
> Gdk.ModifierType.BUTTON2_MASK)
… correctly disable then reanable the drag with buttons 1 and 2 (in
particular, I wanted to verify there was any reason why the property was
G_PARAM_CONSTRUCT_ONLY. Turns out there was no good reason).
I was interested by such API because having long list of parameters in
various APIs is very annoying. It is much nicer to have simple
constructors with decent defaults and proper API to modify a widget
afterwards in order to cater to special needs.
There were some complaint about the height of these scale.
The min-height was clearly too high. I also made the buttons a bit more
compact by removing a bit of padding.
Finally I add a CSS name to the class, in order to avoid using the
parent class name ("spinbutton"). This makes for clearer and more
customizable themes (ability to style the GimpSpinScale without styling
GtkSpinButton too).
The label was simply completely invisible because of broken progress
computation. Now it is visible at least when the progress fully cover
the label, but a part of the label is not drawn when the progression is
smaller than the label. I still have not figured out how to fix this,
though I am starting to wonder if we should not just drop this 2-color
fancy drawing of the label. Clearly the fact we can't get the exact
progression gadget dimension is biting us.
Another issue I noticed when playing with RTL layout is that when
editing the value, it gets printed on the right side (together with the
label) which gets messy. This is also something to figure out, hoping we
get an API for this on the GTK side.
Also I am setting "auto dir" to FALSE on the Pango layout, making sure
it follows the widget direction, whatsoever. In particular, even if the
contents is not RTL characters, we should keep a RTL layout to avoid
completely broken layout.
The logics to get the progress position is not proper because the text
area (as returned by gtk_entry_get_text_area()) is actually slightly
smaller than the progress area. Unfortunately it doesn't look like there
is an API to get the exact progress area. This commit improves a bit the
situation by starting the progress rectangle when excluding the
intersection of 2 rectangles in pango at the start of the text area (not
at 0).
It's still not perfect as the progress width will be anyway a bit too
small and we don't have the data to compute it properly, but it's better
than it used to be. I also set several variables to double instead of
int to be more accurate, though this part doesn't help much.
Finally I used the ink extents rather than the logical extents. Since we
are here to draw, this is the ink extents which is really needed.
Note: for the bug to be visible, you need to have a different text color
for the progress and non-progress part of the scale.
Also I'm unsure about the right-to-left logics which seems very broken.
There is really nothing specific to the core application, it is quite a
generic widget, so it would be nice for plug-ins to be able to use this
widget.
Now the source images are in the build dirs.
Also:
- clean the EXTRA_DIST contents on autotools;
- add dependencies rules in meson gresources to make sure icons are
built before resource build;
- finally remove a duplicate build rule in Color Makefile.
… when appropriate icon failed to be found.
gtk_icon_theme_lookup_icon_for_scale() apparently does all standard
fallbacks, but not the last "image-missing" one which is supposed to
always be present. To avoid crashing, let's add an explicit fallback
ourselves.
We also encountered this on the test-ui unit test because icons are not
installed (but this could happen anyway when running GIMP normally with
third-party icon themes).
When running tests, the data are not meant to be necessarily installed.
Therefore icons won't be found when calling gimp_widgets_init().
Add some special-casing to find them relatively to the install
directory.
… for the container tree view contextual menu.
A very annoying point of contextual menus is that they happen on button
press whereas menu item selection happens on button release. When the
menu corner is positionned on the click position, nothing bad happens;
yet when place is missing on screen, the menu might get positionned over
the pointer position. And worse, the mouse position might be just over
an activatable menu item. So we end up in this weird situation where a
click implies: press, menu opens, release, random item (whatever is
below the pointer) is selected and menu closes.
To get rid of this weird case, let's have our contextual menu happen on
button release. In reality, I don't think anyone cares that it happens
on press or release, you just "click". But what you certainly don't want
is to click random menu items!
To better explain the lock icons, have specific icons instead of reusing
other icons. We also tried to programmatically add the simple lock icon
over the other icons, but we only got ugly render. Better have
custom-made icons.
The gimp-lock icon is the Adwaita system-lock-screen icon, by Jakub
Steiner, simply renamed. Therefore its license is GNU LGPL v3 or
Creative Commons Attribution-Share Alike 3.0.
The other icons are derived from a mix of this same icon and other icons
in our existing set and have the same license too.
Freedesktop (XDG) portals are a collection of D-Bus APIs that work
across desktop environments, display servers and work within
containerized applications, like Flatpak. The internal implementation
can then choose to implement these in such a way that takes into account
security considerations, as well as making sure the user consents to
certain actions.
One such portal is the `Screenshot` portal, which contains a
`Screenshot()` method as well as `PickColor()`. We already use the
former for taking a screenshot, and this commit makes sure our color
picker also makes use of the latter.
By doing this, color picking is now possible on the major Wayland
compositors.
(Honestly, we should remove DE-specific backends like that of KWin, to
have less variation on the possible results of a color picking
operation).
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/1074
This allows us to simplify some of the dragging logic, and makes us a
tiny bit more future-proof for GTK4, which uses a similar construction
with `GtkEventController`s.
While we're at it, stop storing a separate `priv` pointer, which would
allow us to use `G_DECLARE_DERIVABLE_TYPE()` in the future.
This functions has 2 `(out) (array)` arguments, where the array length
is defined by the return value. This can't be expressed in GIR
annotations unfortunately, so just add it as another `(out)` argument.
Also, by default `(out)` args are assumed to be `(transfer full)`, while
these were actually `(transfer container)`.
The GtkContainer::child signal is deprecated and it's write-only,
thus the notify::child signal won't work.
Use the GtkContainer::add signal instead.
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/2928
The variables `screen` and `display` are only for the GDK_WINDOWING_X11
code path.
Fixing the following warnings:
libgimpwidgets/gimpwidgetsutils.c: In function 'gimp_monitor_get_color_profile':
libgimpwidgets/gimpwidgetsutils.c:502:21: warning: unused variable 'screen' [-Wunused-variable]
502 | GdkScreen *screen;
| ^~~~~~
libgimpwidgets/gimpwidgetsutils.c:501:21: warning: variable 'display' set but not used [-Wunused-but-set-variable]
501 | GdkDisplay *display;
| ^~~~~~~
