... "threads" property.
Actually there is no need of having a public GEGL_MAX_THREADS as written
in the previous commit. We can just retrieve the max for a GObject
property.
Raise GIMP_MAX_NUM_THREADS to 64, following the changes in GEGL (see
GEGL commits 6d128ac and f26acbb). This is still considered unstable and
to be used at one's own risk (cf. GIMP commit 1f5739d) but at least, it
could allow discovering and fixing bugs.
It would be nice if GEGL_MAX_THREADS could be public so that to not have
to edit this by hand at each change.
... include mouse pointer.
This is working find and tested under GNOME which already had the code
for it (was only missing the GUI). I added the feature in OSX and X11,
though it is untested. Windows does not seem to have the capability (at
least according to screenshot_win32_get_capabilities() in our code).
- 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.
This patch increases the LCH Chroma slider maximum value from 100 to
200 and also makes the Chroma slider properly display out of gamut
Chroma selections for any given Hue/Lightness combinations.
The current Chroma slider only runs to 100. But quite a few sRGB
colors have LCH chroma values that are greater than 100. For example
reddest red has a chroma of 107, and bluest blue has a chroma of 131.
So it's inconvenient to have to deal with a Chroma slider limit of
100.
Also, the current Chroma slider doesn't properly show out of gamut
areas on the Chroma slider. So for example picking a given LCH Hue and
then moving the Lightness slider doesn't allow to see which Lightness
value allows for choosing the maximum in-gamut chroma for the chosen
Hue.
...on macOS (with macports)
Changed gimp_metadata_get_guid() to use a GRand that automatically
seeds itself from /dev/urandom (if available) or the current time.
and update the grid as soon as a constraint is changed, not only on
the next motion. Change GimpTransformTool to forward the events to the
widget if it exists, but still handle them if it doesn't (yes this
code duplication is ugly, but the widget can hardly handle events if
it doesn't exist...).
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);
s/gtk-application-prefer-gimp-dark-theme/gtk-application-prefer-dark-theme/
I'm actually not sure if this property is supposed to be in the gtkrc
file. It looks like it is available only from GTK+3, and isn't it more
of an application settings in order to select the right theme variant,
rather than a specific theme settings?
Anyway let's at least set the right property name.
Change the text selection to draw an outline around each selected
glyph. It looks just as ugly as before but at least keeps the text
readable regardless of its color.
if did revert to the previous selection and thus break stuff like
enbaling quick mask or inverting the selection, because I merged the
undo magic it does into gimp_rectangle_select_tool_halt(), whereas
before it was done by the former gimp_rectangle_tool_cancel(), so only
on explicit cancel not HALT from whatever source.
Do the same in the new code and move the undo magic from halt() to
rectangle_response(CANCEL), which is exactly the same distinction as
with the old GimpRectangleTool code.
When the user provides a filename without an extension in the save
dialog, we add one for them, update the filename in the dialog, and
retry. However, the updated filename is made up of only the
basename, leaving out the dirname part, if specified. This means
that if the user enters "/somedir/somefile", the new filename
becomes "somefile.xcf", which refers to the current directory,
instead of "somedir".
Fix this by maintaining the dirname when adding a file extension.
Don't unconditionally call COMMIT in rectangle_response(), because
that now implicitly HALTs the tool. Instead, check if we got here
because of a click, and call our commit() directly.
they will all be plain filters soon enough, can just remove them
already and clean up the menu.
Also put the tools which don't modify the image together in a group,
enclosed by separators.
which is the same as g_object_class_list_properties() but filters
out the properties for which we don't want to create a GUI.
Use it in gimp_prop_gui_new().
GimpOperationTool's aux inputs were not properly ported to the new way
filter tools work (complete destruction and re-creation of the tool
dialog).
Split creating the operation GUI and adding it to the dialog into
separate functions, and call them at the right places.
Call HALT generically in gimp_tool_control() after calling COMMIT, and
remove all hacks in tools that call both COMMIT and HALT or call
halt() from commit().
Some tools interact with their subclasses (e.g. filter tool and
operation tool), and it's essential that COMMIT runs through the
entire class hierarchy before HALT.
Probably breaks something, please test.
Michael Natterer