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.
Nikc