which will be shown when selected template pixel density don't
match the image pixel density.
Then user can either keep current image ppi and scale the
template or set image ppi to match the template ppi.
Density selector displayed only when template and image ppi
differs and template unit is matches one of real world units
(e.g. inch, mm, etc).
Closes: GNOME/gimp#1140
This should not be necessary and I could not find the bug in GIMP. It
might be in GTK. In any case, after hiding, then showing back the export
dialog, the file name is right but not the output folder (apparently
revert to current working directory?).
With this, we force it to be the same folder as we left the dialog.
The gimp_drawable_type() is an issue though as gimp_drawable_get_type()
is already defined as a common GObject API.
Though I'm actually wondering if GimpImageType is well called. Rather
than Type, shouldn't we go with ColorModel?
sed -i 's/\<gimp_drawable_bpp\>/gimp_drawable_get_bpp/g' "$@"
sed -i 's/\<gimp_drawable_width\>/gimp_drawable_get_width/g' "$@"
sed -i 's/\<gimp_drawable_height\>/gimp_drawable_get_height/g' "$@"
sed -i 's/\<gimp_drawable_offsets\>/gimp_drawable_get_offsets/g' "$@"
s/gimp_image_base_type/gimp_image_get_base_type/
s/gimp_image_width/gimp_image_get_width/
s/gimp_image_height/gimp_image_get_height/
Sorry plug-in developers, more porting work! But really this seems like
the right thing to do in order not to get stuck with inconsistent naming
for many more years to come.
… and s/gimp_parasite_flags/gimp_parasite_get_flags/
It is better to have a consistent API and the fact is that most
getter/setter functions use the _get|set_ naming, but these didn't.
I wondered if this was such a great idea to rename these anyway because
even though we are breaking API in GIMP 3, is it the best idea to rename
when no functional change happened? After discussing with Wormnest, we
still agreed it was still better to go for consistency rather than
regret later (and be stuck with these names for many more years).
Also this fixes these warnings:
> [649/1205] Generating gimp-3.0.vapi with a custom command
> Gimp-3.0.gir:24162.7-24162.56: warning: Field `Gimp.Parasite.flags' conflicts with method of the same name
> Gimp-3.0.gir:24318.7-24318.52: warning: Field `Gimp.Parasite.name' conflicts with method of the same name
Removing this check makes the treatment of LittleCMS consistent with
all the other dependencies checked in the same file, which only check
that the runtime version is at least the required version.
As long as we were compiled against LittleCMS >= 2.8, and are now
running against a version that has at least the same symbols, it doesn't
necessarily matter whether the version we are running against is the
same one we were compiled against.
Distributions like Debian and Ubuntu track the versions in which
individual symbols were introduced, which allows runtime dependencies
to be weakened when no newer symbols are actually used; this is
practically necessary when working with very large numbers of packages,
to avoid a new version of a dependency library unnecessarily blocking
upgrade of dependent packages. However, this doesn't work if dependent
packages add their own checks that bypass this mechanism.
Signed-off-by: Simon McVittie <smcv@debian.org>
LittleCMS 2.12.0 defines LCMS_VERSION as 2120. We want to print that
as 2.12.0, not 2.2.0.
Resolves: https://gitlab.gnome.org/GNOME/gimp/-/issues/6505
Signed-off-by: Simon McVittie <smcv@debian.org>
I always found the docs misleading because when it says "Returns the
list of layers contained in the specified image", I really read "all the
layers, at any level", except it doesn't. It only returns the root
layers and it is up to the plug-in developer to loop through these if
one needs to go deeper.
So let's make the function docs clearer.
… drawable array instead of a single drawable.
Instead of expecting a single drawable, GimpImageProcedure's run()
function will now have an array of drawable as parameter.
As a consequence, all existing plug-ins are broken again. I am going to
fix them in the next commit so that this change can be easily reviewed
and examined if needed later.
I only fix the Vala demo plug-in now (or rather, I just use the first
layer in the array for now) because otherwise the build fails.
The new function gimp_procedure_set_sensitivity_mask() allows plug-ins
to tell when a procedure should be marked as sensitive or not.
gimp_procedure_get_sensitivity_mask() retrieves this information.
Currently plug-ins are automatically marked as sensitive when an image
is present and a single drawable is selected. Nowadays, we can have
multiple selected layers so we should allow plug-ins to tell us if they
support working on multiple drawables. Actually we could even imagine
new plug-ins which would be made to work only on multiple drawables.
Oppositely, there are a lot of plug-ins which don't care at all if any
drawable is selected at all (so we should allow no drawable selected).
Finally why not even imagine plug-ins which don't care if no image is
shown? E.g. plug-ins to create new images or whatnot. This new API
allows our core to know all this and show procedure sensitivity
accordingly. By default, when the function is not called, the 1 image
with 1 drawable selected case is the default, allowing existing plug-ins
easier update.
Note: this only handles the sensitivity part right now. A plug-in which
would advertize working on several layer would still not work, because
the core won't allow sending several layers. It's coming in further
commits.
See the comments in MR!424.
Basically realpath relies on false assumptions (probably ones which used
to be true when the API got created) on the max size of a path. Actually
nowadays paths can be much bigger than what the macro advertizes or can
even be unbounded.
The Linux version of realpath() allows the second parameter to be NULL,
in which case it would allocate the buffer, exactly for this reason
(written in the BUGS section on the man). Unfortunately this behavior is
not standardized in POSIX and the man from Apple I found does not
indicate it will do this.
So let's use g_canonicalize_filename() instead, which seems to do the
right thing. Similarly use g_strdup_printf instead of g_snprintf().
Crop tool used stale color / pattern values when performed crop with
'Allow growing' option. Its context was not notified when fg/bg/pattern
value was changed.
Closes: #4103
Was caused by widget tool fixed_center_x and fixed_center_y coordinates set to
coordinates of mouse click instead of rectangle center after converting channel
selection bbox to rectangle.
Now rectangle fixed_center_x and fixed_center_y coordinates are always updated
when tool widget x1, x2, y1, or y2 coordinates are updated.
Closes#6487
It isn't being used by any plug-in or any code in GIMP at all even.
Let's get rid of it while we can still break API, so we can cut down on
all the complexity of the gimp-param stuff a bit.
Allow guides with off-canvas position since we can now view and work
outside the canvas.
The guide deletion interaction does not change too much, except you
don't delete a guide because it's dropped off-canvas but off the display
viewport area instead.
The XCF format is technically unchanged as PROP_GUIDES was already
expecting an int32 coordinate (with max value at GIMP_MAX_IMAGE_SIZE,
way below uint32 max anyway). Yet our code and XCF docs was explicitly
asking to ignore negative coordinate guides, which makes a change in
behavior for the XCF parser, hence a new version XCF 15. Loading will
still ignore negative position guides (even also bigger than image
dimension guides now) for XCF 14 and below, but will now accept any
position for XCF 15 and above.
This commit also makes snap to grid and snap to vectors work off-canvas.
Since we now have off-canvas viewing, it just makes sense that snapping
would work there too.
Note that I disable snap to grid when "Show All" is OFF. I am actually
unsure this is right (as "Show All" is a view action, and we usually
don't change behavior based on view actions; for instance snap to guides
are not disabled if guides are hidden). Yet I noticed we do this in
various other features when off-canvas. We kind of use this view flag as
a switch for features working off-canvas (for instance, color picking
works off-canvas only when "Show All" is ON). So let's keep the same
logics for now at least.
Snap to guide or snap to vectors will always work though, because guides
and vectors are always visible off-canvas (even when "Show All" is OFF).
They always have been (visible, not snappable off-canvas; now they are
both).
Our error/message handling code was checking if the status bar label was
big enough to hold the message by checking the GtkLabel allocation. This
means that error message ended up on status bar only if a status text
bigger than the error message was previously displayed.
Even setting gtk_widget_set_hexpand() or the "expand" container child
property on the label, I could not find a way for GTK to actually give
it as much space as possible on the status bar.
Instead, I am computing the full container box size, starting from the
label x coordinate (assuming the label is the last shown widget on the
status bar, as usually the progress bar and the cancel buttons are not
shown in the same time as the message label). This gives me a much more
appropriate result of the maximum size which this label can hold without
ellipsizing.
Adds option for selecting predefined page sizes using the same
template selector as on "New Image" dialog.
Syncs up size and offset unit selectors to have the same value
when changing template and when resetting whole dialog.
See the discussion in #5339. Basically this is now technically a tool
(i.e. a child class of GimpTool) and tools can be activated anytime,
even when no images are opened, i.e. when they are useless (for instance
paint tools). Filters on the other hand were historically only
activatable with opened images. With time, tools and filters difference
got slimmer (until there are technically none nowadays where GEGL ops,
levels or curves are implemented as GimpTool too) if not only a
conceptual difference.
Since here GEGL Operation is really more on the "filter" side, let's
just move it to the "Filters > Generic" submenu, just next to "GEGL
Graph", also removing the mention of it being a "tool" from the help
message.
Then I will merge !402 for it to be (in)active depending on images, as
other filters do.
Since we now hide the file dialog when exporting, progression ends up
invisible, which is especially a problem with big files. Therefore use
the image display as a GimpProgress to show progression.
When running several times an export plug-in while one is still running,
the export file dialog may get destroyed and the second running plug-in
would try to call functions on a destroyed dialog, hence crashing core
GIMP.
XMP metadata saved by GIMP 2.8.x or earlier can have duplicate tags
making the XMP data invalid. There's not much we can do without a
whole lot of processing and complicated code and even then no
guarantee we would catch everything.
Instead let's just try to improve the message to the user so they
will be more likely to understand what's going on.
Using a `GtkListBox` allows us to make more complex widgets when trying
to showcase an icon theme. For example, we can make the example icon a
bit bigger so you don't have to squeeze your eyes to distinsguish them
one from another.
Other possibilities we can do with this widget, is for example making
the folder label clickable to open the file explorer, or add a flat
button at the end with the same purpose. Since it's now just a
`GtkLabel`, we can also make the path selectable (for copy-pasting).
Using a `GtkListBox` in the "Image Window Title & Statusbar formats"
preference pane allows us to make more complex rows, such as adding a
visual example of how the format string behaves on a given image title.
This commit just converts the `GtkTreeView` into a `GtkListBox`, so
nothing has functionally changed (yet), except that rows now give
feedback when the user hovers over them.
Although I haven't been able to reproduce it, it is apparently
possible to get a Stack Overflow when loading xcf files with
presumably very large dimensions on Windows. From what
I'm reading Windows normally has a smaller stack size than
Linux, probably why it hasn't surfaced there.
Instead of allocating on the stack let's do a g_malloc0
combined with g_free.
The `precision` parameter in particular had no min/max, which meant we
could provide a forbidden parameter (e.g. a negative precision) which
would cause a core CRITICAL. We must forbid illegal values from PDB side
(hence outputting a normal plug-in error message, not a core bug).
Also improving a bit the description of this parameter as I was
wondering what precision was needed exactly to get a stroke length. This
is the precision for determining whether a portion of the stroke is
"straight enough" or if we want to break it into smaller pieces until we
get a straight portion.
All it will mean is that we are looking for perfectly straight lines
when deciding if a bezier curve can be considered straight. It's a fair
condition and represents perfectly what a precision of 0.0 would mean.
… apply to GIMP GUI not text layer rendering in image.
Reviewer note: this is the theoretical fix, but it won't work right now
because Cairo explicitly bypasses grayscale antialiasing when system set
subpixel one. Still let's push this first patch, but the issue will be
actually fixed when Cairo will merge my MR too:
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/114
The tool now takes care of the portion of the layer effectively displayed
on the screen. This allows faster expansion/shrink of the selection since
an area smaller than the whole layer is used.
It will also limit the impact of the incoming multilevels processing, which
tends to decrease the segmentation accuracy on thin structures, since users
often zoom-in to work on such thin details.
By default, GTK keeps on showing client-side decorations when going
fullscreen, as it might contain buttons or other functionality that
would be lost. As such, we have to make sure we hide the titlebar.
Getting to that titlebar to update its "visible" property needs a bit of
effort, since it's an internal child of the GtkWindow that isn't exposed
in any way, so we take a little detour using `gtk_container_forall()`.
Most important of all, we shouldn't assume that if a given GDK backend
is enabled at compile time, that this is also the one that is being
used. For example, on Linux, both `GDK_WINDOWING_X11` and
`GDK_WINDOWING_WAYLAND` can be set, but you still need to do a runtime
check if you're running under one WM or the the other.
A small cleanup is that we immediately check if a widget is realized by
checking if it's `GdkWindow` is NULL or not and return immediately
(since we need to check its type later on anyway).
Finally, we can remove `GDK_NATIVE_WINDOW_POINTER` as that is a GTK+ 2.0
construct, so it's dead code anyway.
Setting the `"transient-for`" property for popups is important to
certain window managers (such as Wayland), so that they know what the
parent surface is and can position the popup accordingly.
This fixes the `GimpTagPopup` in wayland giving a critical message, and
getting a random position somewhere on the screen.
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. For this reason, we should try to use
`g_object_notify_by_pspec()` instead.
When run with GIMP_DEBUG=Gtk we get a lot of debug warnings for GimpRuler and once in a while for GtkScrolledWindow that State 0
doesn't match state 128 set via gtk_style_context_set_state (). This happens because we didn't enter the current state flags of
the widget but 0 and apparently Gtk isn't happy about that.
Let's fix this by using the actual state flags by calling gtk_widget_get_state_flags.
Based on other tools wording, as well as the algorithm description. In
any case, it looks a bit better than the previous description (with a
typo even).
In gimp_dialog_factory_register_entry(), strings were passed to gettext
without checking for a NULL pointer. The gettext documentation [1]
points out that that's undefined behavior, and musl libc's
implementation of gettext segfaults in that case.
[1] https://www.gnu.org/software/gettext/manual/gettext.html#Interface-to-gettext
If setting a RGB or Grayscale "preferred" profile, it usually means
these are profiles we are commonly working with, and it is to be
expected that images one might load may already have said profile. In
this case, don't ask what to do with this profile (keep, convert…). The
graphist kind of already answered this by explicitly listing this
profile as a "preferred" one.
Note that I also check for the built-in profile equality, though it
doesn't look like it is useful (gimp_image_get_color_profile() will
return NULL for an imported image which uses the built-in profile).
This is mostly to be thorough.
In some cases, error dialogs may end up below other windows and stay
unnoticed because of how dialogs are raised and hidden on various
platforms. This is not very constructive. It's much better to make sure
one sees an error when it happens (in some cases, it may mean possible
data loss, so it should be at least acknowledged; also seeing it later
may mean you can't know anymore which action triggered this error,
making the whole process kind of meaningless and hard to debug).
So anyway, let's make error messages prominent by having them always
above.
We are piling up the export dialog, then the specific plug-in dialog,
then possibly more dialog (cf. upcoming commits for metadata handling).
It's just too much and we end up in a mess of dialogs.
Of course, if the export fails or it is canceled, we are back to the
file dialog, which gets shown again, whereas if it succeeds, the file
dialog is destroyed (just as it already used to be).
Also anyway the file dialog is completely deactivated while the export
dialog is displayed, so it's just useless. Finally some export support
have features where looking at the canvas is useful, for instance JPEG
preview feature. With all these dialogs, it's nearly impossible to look
at the canvas (with a single display at least).
If you hover over the GimpSpinScale while clicking Shift, we want to be
able to advertize the fact that it will produce a different action than
the simple click. It makes the widget behavioral rules actually
discoverable.
Aryeom noted that current top arrow cursor comes from a time when the
interaction with this widget depended on a lower versus upper region and
doesn't gives anymore any idea of what the click would do.
So let's replace the top-arrow cursor with a "grab" cursor, which even
becomes a "grabbing" cursor when a grab is in progress.
Also let's now use gdk_cursor_new_from_name() with standard names from
the CSS specification, because it is the recommended way. According to
GDK docs, GDK cursor list is taken from the X cursor font and apparently
not all cursors are available on all platforms. So let's use the
standard CSS list, whose cursors are said to be available accross
platforms (at least very very likely, I guess).
Finally I renamed the target enum for the widget to be more semantic
than upper/lower which don't mean anything anymore in our new
interaction rules.
Currently to edit the value with the keyboard (i.e. get a focus on the
text entry part of the widget), we can click on the scale which gives us
edit focus, but it implies to change the value (which may not be
wanted).
An interaction method exists to do just this, which is the secondary
button (middle click). Unfortunately, though powerful, it is totally
"hidden feature". People expects to be able to click on the numbers they
see and start typing.
This change allows just this. Now when clicking on the number part, it
selects the whole text input contents (same as with middle-click ever
since commit 3449652fe8), without changing the value. You just enter in
text input mode.
To properly advertize the behavior change, the cursor will also change
when hovering, showing a text cursor over the existing number text.
As many of my changes, this change was designed together with Aryeom and
triggered originally by her usability feedbacks and inputs.
We were also reading "gtk-show-unicode-menu" which has also been
deprecated since GTK+3.10, and we were not even using the read value.
Just remove this piece of unused code.
The input menu added with gtk_im_multicontext_append_menuitems() mostly
provides redundant (e.g. the system defaults) or useless options
(e.g. "None" or "Simple" which basically seems to mean the keyboard
mapping straight keys, and I don't see why anyone would want this if one
set a system-wide input system). Worse it can provide unstable options
(e.g. "Wayland" which crashes GIMP when I tried it on my X11 desktop! It
crashes on _gtk_immodule_wayland_init which is probably normal as we are
not on a Wayland client).
Anyway gtk_im_multicontext_append_menuitems() is deprecated since
GTK+3.10, as well as the "gtk-show-input-method-menu" property which we
read from GTK+ settings (and is FALSE anyway nowadays by default, so we
usually never show this submenu) to determine if we should show this
additional text tool submenu or not. Furthermore there is just no reason
not to leave the defaults system input method engine does its job (which
works well as far as I can see, at the very least on my GNU/Linux X11
desktop and on Wayland also, last I tested).
Check at runtime for the operation availability and set the "Show Image
Graph" action active depending on this check.
This goes with discussions to make this operation optional with a
runtime check for the tool `dot`.
See: https://gitlab.gnome.org/GNOME/gegl/-/merge_requests/84
gimp_channel_select_alpha() was creating the same undo label "Alpha to
Selection" whatever the actual operation (add, remove, replace,
intersect). Select the right label depending on the actual operation.
… Selection.
I first wanted to switch the modifiers to Alt+shift, Alt+Ctrl clicks and
even implemented the changes, but realized the existing "Alpha to
selection" on Alt thumbnail clicks already mapped these for
Add/Remove/Intersect Alpha to Selection (though I broke this with commit
14b4c08881 but re-allows properly with exact modifier recognition in
order not to catch other types of combinations).
In the end, I see no other solutions than actually removing the mask
add/remove modifiers (#if-ed 0 for now, we'll see) in favor of the most
ancient feature.
Another sensible default change proposed by Aryeom. Until now, all tools
which could make use of dynamics started with "Dynamics Off". This makes
it very hard for beginners to start using GIMP with a tablet directly
without actually knowing the technical settings of the software.
This is even more anticlimactic in GIMP 3 as tablet are supposed to work
from scratch (and they do), but without a proper dynamics, you can't see
it. And same as it used to in GIMP 2.x, at first launch, it looks like
your tablet is not recognized.
We hesitated between "Pressure Size" and "Pressure Opacity". Both are
sensible choices and would directly show your tablet works. Also they
rely entirely on tablet-specific input (pressure), unlike e.g. speed or
direction, which is much better for the purpose of showing the tablet
works and is properly supported.
… multi-selection modifiers. Also they will work from now on on the
clicked mask only.
Shift and Ctrl clicks are reserved for multi-selection. We do not want
these to do other actions if you shift|ctrl-click on a mask (even more
as these alternative actions are hardly discoverable so it would make
for bug-like behavior to the person not knowing these alternative
actions).
So Alt-click is still used for showing/hiding the mask, but
enabling/disabling changes from Ctrl-click to Alt-Ctrl-click.
The second change is that these actions will not run the actions on
selected layers' mask, but on the clicked layer mask. This will at least
make these interaction different from the actions (e.g. with contextual
menu) and therefore it's not even redundant anymore. We will now have a
way to work on all selected layers vs a way to work on a clicked layer
(without changing the existing selection).
When Alt-clicking on an item thumbnail (for instance a layer thumbnail),
we can trigger an "Alpha to Selection" action on the clicked item. Yet
the check was not accurate and would work on Alt+any modifier(s)+click.
Let's catch exactly Alt-click only in order to allow for more actions on
other combinations.
In particular, we should not check if the extend/modify (shift/ctrl)
modifiers are ON, but also that no other modifier is ON. For instance an
Alt-Shift-click should not trigger multi-selection actions, allowing it
to be useful for other actions without also changing the selection in
the same time.
Long press on a viewable cell (such as the small layer or mask preview)
pops up a slightly bigger preview. We don't want this feature to be
triggered when any modifier is active, such as ctrl/shift (common with
multi selection in a tree view) or alt combinations (for various
alternative actions).
A UI unit test (paintbrush_is_standard_tool()) was expecting the
paintbrush tool to be the default tool. This actually does not fit with
my tests as the crop tool was always the default tool if I were to
delete my config folder and start anew. Yet it was working for the unit
testing at the very least since `make check` used to work until now, and
was broken by my change.
Anyway with my new code (commit 31e38fe869) and this additional one, now
it should work both for unit tests and real usage. So this commit fixes
both the CI and the originally expected default tool.
For the record, Aryeom also agrees that paintbrush is a good default
tool for first usage/discovery of GIMP.
This code is the result of discussions with and propositions by Aryeom
who thinks (and I agree obviously) better defaults should be set for
beginners and first time users. This is only a first change, more
similar defaults updates will likely come in the next few months on
various parts of GIMP.
Existing code was only making a differenciation for eraser-type devices,
setting them to the eraser tool (which is fine of course).
So far, I only added 2 types of device source, which we should
definitely special-case as well: pen tools (tablet styluses) should
definitely map to the Paintbrush (pencil could be a reasonable defaults
too, though brush seems much more common); as for touchscreen, I chose
to map to the Smudge tool (though to be fair, if we had gesture
recognition, this should not map to any tool). I also set a generic
default now because it seems that right now, we don't specify anything
(it ends up defaulting to the Crop tool for first uses, at least in my
case). I set the rectangle select tool. I'm not sure it actually makes
particular sense, but at least it's probably better to default to
something not destructive for first time users.
Virtual devices are only reflection on the various physical devices
attached to it (mouse, touchpads, styluses, etc.). Keeping settings when
the device is updated just makes no sense. Worse it can actually cause
issues by setting axis uses from one device where an axis use is 'none'
(and it's normal) to another where 'none' ends up disabling the axis.
Earlier code was assuming it should not happen. Actually it can happen,
in particular with virtual devices (on which several physical devices
can be attached and switching to one or the other would update the
virtual device to mimick its features).
It's just better practice to not leave all these variables public,
implicitly allowing various code to use these directly (also making
debugging harder).
Axis names can now be returned with gimp_device_info_get_axis_name() and
I added a dedicated function gimp_device_info_ignore_axis() to handle
the case of an axis to ignore.
I also improved the code with less redundancy to handle the axes data
(both the use and name arrays will always exist and be created and will
be n_axes size, hence avoiding bad out-of-bound reads). This includes
some code refactorization avoiding near code duplication to make sure we
always have the same logics, by creating the gimp_device_info_updated()
static function.
The issue has also been fixed on GEGL side (see commit 5ac40e3c3 in
GEGL), but since the fact that "gegl:introspect" relies on a runtime
tool (which is not the best thing), let's make an additional check
within GIMP to make sure we have a proper buffer as a result to
"gegl:introspect". Otherwise we might crash when trying to use this
NULL buffer.
- First only show the axes returned by GDK (which means the axes
returned by the driver if I understand correctly), and even within
these, ignore the ones set as "ignore" because they are likely bogus
axes (Carlos said drivers sometimes add a bunch of axis; I am guessing
this is because many are generic drivers for various models of tablets
so instead of have variable length of axes, they just set some to be
ignored).
- Also use the names returned by GDK instead of our fixed set of names.
The main advantage is that these are more accurate. For instance
rather than showing just "X" for the firxt axis, the GDK names would
be "Abs X" for a tablet and "Rel X" for a mouse. The drawbacks is that
it doesn't look like GDK is actually translating these, and since we
don't have the strings in our code, we don't either. This will have to
be figured out.
Note that we still need to use the fixed set of names
(axis_use_strings array) when a device is disconnected.
- If some device didn't have any axes at all, don't show an empty list.
Don't show the curve widget either.
- In the Axes list, select by default the first axis with curve (which
would be only pressure so far if a device has this axis), because this
is one of the main feature still doable with this dialog, so it's a
bit of a time-waste if we don't show this directly. In no axes has a
curve, just show the first axis in the list.
… gimp_label_spin_set_digits() and deleted gimp_prop_opacity_entry_new()
- The "digits" argument for the number of decimal places in
gimp_prop_scale_entry_new() is now mostly useless since GimpLabelSpin
(hence GimpScaleEntry too) got a nice estimation algorithm of sensible
values.
- Add gimp_label_spin_set_digits() function to manually set the digits
property when we don't like the estimated value.
- Also add a new "factor" argument to gimp_prop_scale_entry_new(). Its
role is to allow a GimpScaleEntry showing a factored range, typically
a [0, 100] range for some types of [0, 1] properties.
- Remove gimp_prop_opacity_entry_new() which was basically a
special-case of gimp_prop_scale_entry_new() and which can now be
easily reproduced by simply set factor=100.0.
- Update all usage of gimp_prop_scale_entry_new() in app/ and plug-ins/
with updated arguments. It is interesting to note that all existing
usage were either integers (digits=1) or when double, the estimated
decimal places are the same as the ones which were manually set (hence
showing the generic estimation is not too bad). So the new function
gimp_label_spin_set_digits() was not even needed once in current code.
A -quick done- first step towards the addition of a smart selection tool.
Require the gegl:paint-select workshop operation.
Still LOT of work to do (wip):
- fluctuations removal (GEGL side)
- multilevels pyramid approach + banded graphcut for instant result on large
image (GEGL ? GIMP ?)
- Gaussian Mixtures for color models (GEGL side)
- drawable offsets (GIMP side)
- undo / redo (GIMP side)
- scribbles edition mode (GIMP side)
- dedicated icons
- ...
… in Image properties window.
Basically using non-translatable "%s (%d %s)" and filling it with
"Indexed color" base type name and translatable _("colors") is very bad
practice (localization-wise):
- First it assumes everyone uses round brackets.
- It also assumes the order of words (number before word it determines
but even the image type before detail brackets).
- And finally it doesn't handle plurals. Of course, we could say that
the 1 color case is a very edge impractical case, but plural is not
only about 1 vs other numbers. Some languages have more cases, and
using ngettext allows translators to handle these.
First of all, "CJK Unified Ideographs" block should not be the highest
priority to determine showing an ideograph. Indeed most fonts for a
Korean and Japanese audience would also contain at least the main
ideographs. So instead, look first for Korean alphabet (Hangul) and
Japanese syllabaries to determine if it's a Korean or Japanese-targetted
font. Only then Chinese.
Also check Korean before Japanese because most of the Korean fonts I saw
actually also include Japanese syllabaries (but not the other way
around).
This way, it will be much easier for CJK graphists to skim through the
font list and detect fonts made for the needed language in a glance.
Also modifying the Korean display text. KIYEOK and SSANGKIYEOK were
obviously chosen because they were the first in the block. But they are
very bad choice. We hesitated with 가 at first, as it is considered the
first in the syllabary form (가나다라 is kind of similar to our ABCD).
But it wouldn't show a form with a second consonant (below) which is a
good stylistic indication. So we hesitated between 한 (han) and 글
(geul, which also means text so it's a nice sample), and finally went
with 한 because of the circle shape in ㅎ (hieut) but also its small
"hat" which has many stylistic variants. So it's quite a good hint of
stylistic choices made by a font designer from just the sample box.
Moreover I switched the block check from "Hangul Jamo" to "Hangul
Syllables" block. "Hangul Jamo" are positional forms of the letters to
dynamically compose syllables (in particular legacy syllables not in use
anymore). Though a feature-full Korean font set would design these, it
is less important than "Hangul Syllables" (pre-composed syllables
design) or "Hangul Compatibility Jamo" (basically the same letters as
"Hangul Jamo" but for standalone usage). Also I actually saw some fonts
made for Korean without "Hangul Syllables" support.
Finally I also added a test for Japanese. I check the Hiragana block
which is most likely the most basic which has to be in any
Japanese-targetted font and use 'あ' (a) as sample text, which is the
first Hiragana syllable and here definitely a good sample text in my
opinion.
I believe that this can still be improved though. Checking only a single
block to determine the probable target language is not necessarily
enough. For instance very complete fonts for Chinese may also design
Korean and Japanese characters, but will also have most CJK blocks and
more ideographs (whereas Japanese/Korean will likely have less). Yet
let's say this is good for now, at least better than before!
pango_fc_font_lock_face() is deprecated since Pango 1.44.
This may hopefully also fix#5922 as I completely changed the code where
the CRITICAL happened. Yet I left g_return_val_if_fail() to check if the
Harfbuzz font and FreeType face variables are not NULL (because looking
at the code, it looks like these functions returning NULL actually means
there is a bug in the code).
Nevertheless if it turned out that there are non-bug cases where these
could return NULL (for instance a broken font file?), then probably we
should not use g_return_val_if_fail(), but instead address the data
issue in a nicer way.
Bumping harfbuzz dependency to 1.0.5 for hb_ft_font_set_funcs(). Without
configuring the Harfbuzz font with it, hb_ft_font_get_face() always
returns NULL.
Note that it looks like hb_ft_font_lock_face() would actually be better,
but this requires harfbuzz 2.6.5 from last April which is quite recent.
So let's just use the get_face() variant for now.
The color space label may be a bit long (depends on profile title which
may just be anything and we don't control it), so I allow it to wrap.
The file path on the other hand would not work well with wrapping. It
already has ellipsis in center, but GTK always gives the max size it can
as a default. So if the file is even just slightly deep in the file
tree, we end up with extra-wide Image Properties dialog.
My trick is to give a sensible max size at dialog creation (25
characters max) but to disable this max size as soon as the window gets
realized, hence allowing the label to actually grow up to the contents
actual max size, were one to manually resize the window.
"RGB color" is not a color space, only the model. To get full color
space information, we want to display the model and associated profile
name.
Of course, the "Image Properties" dialog also has a tab displaying
details about the color profile. Still it's better if the general info
displays not too wrong label contents.
Note: when the used color profile has no name, it will show "(unnamed
profile)" which is still more informative than just the color model.
- Set the software as `initialized` later, and in particular after all
recovered images (from crash) then all command line images were
opened. The reason is that the DBus calls have necessarily been made
after GIMP was started (typically could be images double-clicked
through GUI). We don't want them to appear before the images given in
command line (or worse, some before and some after).
- Process DBus service's data queue as a FIFO. The image requested first
will be loaded first.
- When a DBus call happens while GIMP is not initialized or restored,
switch to a timeout handler. The problem with idle handlers is that
they would be attempted too often (probably even more during startup
when no user event happens). This is good for actions we want to
happen reasonably quickly (like would be normally DBus calls), but not
when we are unsure of program availability schedule (i.e. at startup).
Here not only the handler would run a lot uselessly but it would
likely even slow the startup down by doing so. So while GIMP is not
initialized, switch to half-a-second timeout handler, then only switch
back to idle handler when we are properly initialized and GIMP is
ready to answer calls in a timely manner.
Stanislav Grinkov