Looking further at this widget, many things are not right. Here are the
changes:
- Use binary prefixes (i.e. kibibyte, mebibyte and gibibyte) instead of
decimal ones. We are making binary shifts so we were actually showing
the wrong units.
- Round the value to the closest integer when showing it, not towards 0.
Otherwise I had cases where it was showing 7GiB for an actual value of
7.69GiB (default as computed by GIMP from my actual physical memory).
Note that I am actually unsure even rounding makes sense. Shouldn't we
rather show double values with a few digits after the decimal points?
For such values, I think it would make sense.
- Do not edit the internally saved accurate value when the entry is
edited to the same less accurate value as our saved value would be
shown too. In particular when changing the display unit to a bigger
one, we don't want to lose accuracy. This is especially true for low
values. Say you don't have a lot of memory and you set the Tile cache
size to 1.5GiB (1536MiB), you certainly don't want it to become either
1 or 2GiB when switching display unit to GiB. Now even if the number
will still display with less accuracy, the internal value will stay
accurate.
This bug doesn't happen when setting value through the GUI as in such
case, the unit never changed. It happened when setting a value which
could not be properly displayed by current unit (typically smaller than
1 in this unit, or with remainder).
In such a case, we should not manually set private->shift before
gimp_int_combo_box_set_active(), or the callback was failing to
reconfigure the GtkAdjustement, in particular min and max values.
As a consequence, hitting a Preferences reset, with a GimpMemSizeEntry
in Gigabytes, it got reset to Kilobytes with the max values capped at
4096. So I realized a Reset ended me with a Tile cache size of 4096 KB
in particular, which is of course ridiculously small and would be a
problem if one doesn't notice the issue immediately.
In GimpSpinButton, don't propagate Enter key-press events if
updating the spin-button's value in response changes the entered
text. This prevents confirming dialogs when hitting Enter after
entering a math expression in size entries, updating their value
instead.
Likewise, don't propagate Escape key-press events if a new value
was entered, and restore the original value instead.
`gimp_unit_store_get_value()` clashes with the `get_value()` method of
its parent class GtkTreeStore. This means trouble for bindings, as seen
here in some pseudocode:
```vala
var unit_store = new Gimp.UnitStore();
// Which function are we referencing here, the one from GtkTreeStore or
// the one from GimpUnitStore? Worse, they both have different arguments
unit_store.get_value( ... )
```
GtkHBox is a deprecated version of GtkBox, which we don't even use
anymore. It confuses the gtk-doc a build though, so let's fix it to get
rid of another warning.
The GIR parser is giving warnings because both e.g. a signal, a
corresponding vfunc and a method emitting it are named
"channel_changed", which can and will give issues in some bindings.
The easiest option is to follow the general convention of starting the
signal emitters with `emit_`, which also makes clear the intention of
the method.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
gimp_int_radio_group_new() was still complaining about the scope of
radio_button_callback(). Make it (scope notified) because it needs to
stay alive after the function returns and may be called multiple times.
Also adding a GDestroyNotify to free the callback data once the widget
is destroyed (additionally it will also serve as a notifier for bindings
to properly free the callback closure itself, not only it's data).
With this last one done, GObject Introspection generation now happens
without any warning output.
In GimpSpinButton, adjust the scroll step in response to modifiers:
normal scrolling uses the step increment, Ctrl uses the page
increment, and Shift scales the step increment down by the ratio
between the page and step increments (up to the minimal precision
of the spin button).
This applies to all spin buttons used in GIMP, including spin
scales.
Add a new 3D Transform tool, based on GimpToolTransform3DGrid,
added in the previous commit. The tool UI provides a notbook with
three tabs, corresponding to the three GimpToolTransform3DGrid
modes:
Camera - allows setting the primary vanishing point, as well as
the camera's focal length, expressed either directly, or as the
camera's angle of view, relative to the whole image or the
transformed item. By default, the vanishing point is aligned
with the item's center, and the angle of view is fixed relative
to the item; this essentially means that each item is transformed
using a local perspective, independent of its position and size
relative to the image. A global perspective can be achieved by
using a common vanishing point and focal length (or an image-
relative angle of view).
Move - allows moving the item using X, Y, and Z offsets.
Rotate - allows rotating the item using X, Y, and Z Euler angles.
The order of rotation of the different axes can be controlled by
a set of numbered buttons next to the sliders, and the rotation's
pivot can be controlled using a pivot selector.
GimpPivotSelector is a 3x3 grid of toggle buttons, used for
selecting a natural pivot position (e.g., for a transform) relative
to an item: its center, its corners, and the midpoints of its
edges.
In GimpSizeEntry, the value corresponding to 0%, as per
gimp_size_entry_set_size(), may be non-zero. This works correctly
when using the size entry in percentage mode, but not when using
precentage as part of arithmetic.
Fix this by adding an 'offset' parameter to eevl's unit-resolution
callback, which can be specifies a constant value to add as part
of unit conversion, after scaling the converted value by the
conversion factor. In GimpSizeEntry, use this parameter to offset
percentages by their lower bound.
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
Noticed by Massimo.
gimp_type_set_translation_domain() calls were missing.
Also make so that the output is exactly similar (even whitespaces) as
the autotools one, making it easier to diff, hence maintain.
In gimp_page_selector_add_frame(), if "gimp-frame" icon cannot be loaded
(which should not happen, but reality can always strike back!), we want
to abort from gimp_page_selector_add_frame() immediately.
Also as a consequence, its return value might be NULL, hence should be
freed with g_clear_object() instead.
This happened here because of broken meson rules (which didn't install
this icon) and ended up in forever looping errors when loading a
multi-page PDF (pages are shown in frames in a dialog):
> (file-pdf-load:12348): GdkPixbuf-CRITICAL **: 11:59:28.513: gdk_pixbuf_copy_area: assertion 'src_pixbuf != NULL' failed
and remove a gazillion gtk_widget_show() all over the place, some
places need a gtk_widget_hide() now, and I'm pretty sure I broke at
least one thing in all those files...
to match gimp_int_combo_box_new(), and add gimp_int_store_new_valist().
Move the va_list of (name, value) parsing code to
gimp_int_store_new_valist() and use it from
gimp_int_combo_box_new_valist().
This makes the entire GimpIntStore/GimpIntComboBox stuff useable much
more generically for the price of an incompatible change of a public
function that is used exactly once outside of libgimpwidgets.
... in their dockable dialog
In GimpChainButton, override GtkWidget::compute_expand() to avoid
inheriting [hv]expand from the button's chain lines, so that these
propeties don't in turn propagate to the widget's ancestors,
screwing with their layout.
GimpConfigWriter contains several constructors with the convention
`gimp_config_writer_new_* ()`. This will lead to problems however with
languages like Vala, where it cannot disambiguate the following:
```
// calls config_writer_new_string()
Gimp.ConfigWriter w = new ConfigWriter.string("xxx");
// calls config_writer_string()
w.string("xxx")
```
Using `from_` in constructors is general practice in GObject-bsed
libraries because of this.
This also fixes an error when trying to use vapigen on the GIMP .GIR
file.
libgimp is anyway processed at the very end after all other libgimp*
were built. This way, it also fixes#3746, by removing the $(top_srcdir)
everywhere from introspected files, hence making the build work again
with older automake.
Basically this commit makes sure that all return values that are marked
as "Returns:" also have a `(nullable)` annotation if it is mentioned on
the same line that NULL can also be returned.
This will prevent a few problems in GObject-introspection.
Documentation-wise in C, this doesn't matter a lot, but it allows
GObject-Introspection based bindings to use their built-in versions when
they want to render any kind of documentation (for example, docs for
Python plugins can render `%NULL` as `None`).
which means that it's now included normally via gimpbase.h
and not any longer via gimpbasetypes.h which we only did out
of lazyness. A *lot* of files in libgimp* and app/ now need to
(skip) various variable length functions (va_list functions are not
introspectable anyway, but adding manual annotations shows we've have
been through them).
Also (skip) gimp_dialogs_show_help_button even though it could be
introspected without any problem. Yet it's written that's an
internal-only function, so let's forbid bindings from using it.
Finally fix gimp_dialog_add_button() introspection by properly including
Gtk-3.0 introspected library so that g-ir-* knows the GtkWidget type.
... gimp_dialog_set_alternative_button_order_from_array()
Macros are not introspectable, which means this call would not be
available for non-C plug-ins. Also adding a "Since: 3.0" since these
macros were added in commit 3be0d13be3.
Note that I don't do the same for the macro
gimp_dialog_set_alternative_button_order() because varargs functions
won't be introspected anyway. So this one can just stay a macro for C
plug-ins only.
Only leave behind gimpcolorscale, gimpcolorscales and gimpcolorselect
for now. There are some GI compilation errors and I don't have the time
right now to look into it. Most of libgimpwidgets is available to GI
bindings now anyway.
Make better subvision, as well as ruler steps, based on what seems to be
the common trends for rulers of these 3 units (inch, foot and yard), but
also based on common conversion needs.
Main changes are:
- Always subdivide inches by 2, down to 1/256, and get rid of the gap
where inches division jumped from 1/16 to 1/192 (which is not even a
multiple of 2).
- Add the 72 steps to inch ruler (1 fathom).
- Replace the 2 feet by a 3 feet (1 yard) step.
- Use base-10 steps for yard (there don't seem to be bigger units in the
imperial/US measurement system which needs specific steps).
- Add the 1/36 yard (= 1 inch) division.
- Below 1/12 feet and 1/36 yard, divide by multiples of 2 (inch-style).
Add a new Offset filter tool, as a front-end to gimp:offset. The
tool replaces, and provides the same interface as, the drawable-
offset dialog, while also providing live preview and on-canvas
interaction.
Note that we don't simply use a custom propgui constructor for
gimp:offset, since we need a little more control.
When the "wrap" property of a GimpSpinButton is TRUE, wrap-around
out-of-range values entered through the spin-button's text entry,
instead of clamping them. Since we're using GimpSpinButton
everywhere since last commit, this applies to all our angle-entry
spin buttons (including spin scales).
This allows to force a GimpColorArea to display as out-of-gamut color.
Current code was only considering the generic RGB case (outside of [0-1]
range), and in particular not grayscale or indexed images.
Ideally the GimpColorArea widget could be (optionally) made to follow a
context, so that for instance it could update its representation when
the context image changes, or when this image's type changes. Yet since
it is a libgimpwidgets widget, it cannot get such update. Instead I add
a new API function to display the color box with the out-of-gamut
triangle. The decision code for this will have to be done elsewhere.
Use this new API for GimpColorHistory to display non-gray colors in the
history as out-of-gamut on grayscale images, or colors absent of the
palette on indexed images.
In GimpChainButton, emit the "toggled" signal whenever the chain
button's "active" property changes, either due to user interaction,
or programatically. Previously, it would only get emitted when the
button was actually clicked.
In particular, this fixes an issue where the aspect ratio of a
coordinates size-entry won't get updated when its chain button got
toggled programatically, as can happen with the scale tool.
We were doing it all the wrong way, fixing one combo box object at a
time. So this commit basically reverses commits 68a33ab5bd, 6dfca83c2a
and a9a979b2d0 and instead runs the same code in the class code. This
way, all objects based on these base classes will have the fix from
scratch.
These improved various other drop-down lists (I found some of them, and
probably not all) as I fixed all GIMP custom widgets based on
GtkComboBox.
Note that it has to be run after filling the list apparently (I had the
problem especially with GimpIntComboBox if running in the _init() code,
then the list widget showed wrong).
...palette views despite selected color being in the currently
selected pallette
As suggested by Massimo, changing the color comparison EPSILON in
gimppalette.c from 1e-10 to 1e-6 fixes this, and is really small
enough.
Also, generally clean up color comparison epsilons:
- use a #define, not hardcoded values for all uses of
gimp_rgb[a]_distance()
- call the #defines RGB_EPSILON and RGBA_EPSILON
- make them all 1e-6 or larger
This was my initial choice, but the more I think about it, the less I am
sure this was the right choice. There was some common code (as I was
making a common composite bucket fill once the line art was generated),
but there is also a lot of different code and the functions were filled
of exception when we were doing a line art fill. Also though there is a
bit of color works (the way we decide whether a pixel is part of a
stroke or not, though currently this is basic grayscale threshold), this
is really not the same as other criterions. In particular this was made
obvious on the Select by Color tool where the line art criterion was
completely meaningless and would have had to be opted-out!
This commit split a bit the code. Instead of finding the line art in the
criterion list, I add a third choice to the "Fill whole selection"/"Fill
similar colors" radio. In turn I create a new GimpBucketFillArea type
with the 3 choices, and remove line art value from GimpSelectCriterion.
I am not fully happy yet of this code, as it creates a bit of duplicate
code, and I would appreciate to move some code away from gimpdrawable-*
and gimppickable-* files. This may happen later. I break the work in
pieces to not get too messy.
Also this removes access to the smart colorization from the API, but
that's probably ok as I prefer to not freeze options too early in the
process since API needs to be stable. Probably we should get a concept
of experimental API.
This commit implements part of the research paper "A Fast and Efficient
Semi-guided Algorithm for Flat Coloring Line-arts" from the GREYC (the
people from G'Mic). It is meant to select regions from drawn sketchs in
a "smart" way, in particular it tries to close non-perfectly closed
regions, which is a common headache for digital painters and colorists.
The implementation is not finished as it needs some watersheding as well
so that the selected area does not leave "holes" near stroke borders.
The research paper proposes a new watersheding algorithm, but I may not
have to implement it, as it is more focused on automatic colorization
with prepared spots (instead of bucket fill-type interaction).
This will be used in particular with the fuzzy select and bucket fill
tools.
Note that this first version is a bit slow once we get to big images,
but I hope to be able to optimize this.
Also no options from the algorithm are made available in the GUI yet.
... as I would like it to.
Use GimpSpinButton, added in the previous commit, in GimpSizeEntry,
instead of GtkSpinButton. This avoids updating the spin-buttons'
adjustment values when they lose focus, truncating the value if it
can't be accurately displayed using the corresponding spin-button's
digit count. Since size-entries can have multiple spin-buttons
using different units, this prevents the value from changing when
entring a value using one unit, and then shifting the focus to, but
not changing, another unit.
GimpSpinButton is a drop-in replacement for (and a subclass of)
GtkSpinButton. Unlike GtkSpinButton, it avoids updating the
adjustment value when losing focus, unless the entry text has
changed. This prevents accidental loss of precision, when the
adjustment value can't be accurately displayed in the entry.
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
This fixes 2 CRITICALs when creating a GimpFrame without a child. There
are reasons to create empty frames (for instance to conditionnally add
contents later, and use it as a label only otherwise).
Add an option to record a performance log through the dashboard.
The log contains a series of samples of the dashboard variables, as
well as the full program backtrace, when available. As such, it
essentially acts as a built-in profiler, which allows us to
correlate program execution with the information available through
the dashboard. It is meant to be used for creating logs to
accompany perofrmance-related bug reports, as well as for profiling
GIMP during development.
The sample frequency defaults to 10 samples per second, but can be
overridden using the GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY
environment variable. Backtraces are included by default when
available, but can be suppressed using the
GIMP_PERFORMANCE_LOG_NO_BACKTRACE environment variable.
Logs are created through the new "record" button at the bottom of
the dashboard dialog. When pressed, a file dialog is opened to
select the log file, and, once confirmed, data is being recorded to
the selected file. Recording is stopped by pressing the "record"
button again (we use a highlight to indicate that recording is
active.)
While recording, the "reset" button is replaced with an "add marker"
button, which can be used to add event markers to the log. These
can be used to mark events of interest, such as "started painting"
and "stopped painting", which then appear in the log as part of the
sample stream. Markers are numbered sequentually, and the number
of the next (to-be-added) marker appears on the button. Shift-
clicking the button adds an empty (description-less) marker, which
is only identified by its number; this can be used when markers
need to be added quickly.
The log is an XML file, containing some extra information (such as
the output of "$ gimp -v", and symbol information) in addition to
the samples. The data in the file is delta-encoded to reduce the
file size, meaning that samples (as well as some other elements)
only specify the changes since the previous sample. This adds a
necessary decoding step before data can be processed; the next
commit adds a tool that does that.
There are currently no tools to actually analyze the data -- that's
still TBD -- but at least we can start gathering it.
AM_PATH_GLIB_2_0 m4 macro actually computes this value using
$PKG_CONFIG. Yet $PKG_CONFIG variable is the pkg-config tool looking for
target libraries (not host), hence it would return the executable
`glib-compile-resources` built for the target.
Also using the same variable name invalidates our test: our own
AC_PATH_PROG was never run as the variable was already set. And no
environment variable could override this test anymore either. This is
why I rename the test variable to HOST_GLIB_COMPILE_RESOURCES.
(cherry picked from commit d1d9eb17e5)
... GimpCellRendererToggle into "icon-size".
In particular making it a pixel size instead of a GtkIconSize. This enum
is limited to a few presets (registering new values is deprecated since
GTK+ 3.10), with names completely semantically wrong. It is better to
specify icon sizes (before scaling) in pixels directly, which goes also
with named icons instead of stock ones.
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06fa1a753fda5b4d46af01698c344154e
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
In subdirs containing a generated foomarshal.h header, add the
generated sources to BUILT_SOURCES, so that they're generated
before the rest of the source files are built. Otherwise, since
there is no rule specifying the dependency between the rest of the
source files and foomarshal.h, and since foomarshal.h is not
checked into git (and hence doesn't exist when doing a clean
build), compilation of the said source files may fail if they're
built before foomarshal.h is generated.
The old hack doesn't work any longer, there is only one cell layout in
GTK+ 3.x, not separate ones for the button and the popup. Switch back
to recreating the cells in notify::popup-shown.
Also simplify the code, we only need to remember one cell renderer in
our struct, and remove manual resizing code that was only needed in
older GTK+ 2.x vrsions.
... GimpMemsizeEntry.
A GtkAdjustment is a GInitiallyUnowned, which means it is created as a
floating reference. GtkSpinButton assumes its ownership by calling
g_object_ref_sink() in gtk_spin_button_new() implementation. Thus it
will take care of freeing it and when we try to unref it in finalize(),
the object already doesn't exist.
Alternatively we could keep another ref (by calling g_object_ref_sink()
ourselves) but since the spin button is a child of the entry, it will
live all the way until the entry is freed. There is no need to increment
the references. So instead, simplify the code, and don't try to free an
object we don't own anymore.
This fixes CRITICAL assertions:
> g_object_unref: assertion 'G_IS_OBJECT (object)' failed
- remove redundant frames, 3d-frames are gone anyway, so no need to
keep double out/in frames around
- give all color selector classes CSS names
- add/fix some theme CSS styles
Set the tooltip in GimpColorHexEntry itself and remove all other
tooltip setting. This just moves the translatable string sround in
libgimpwidgets/, and even removes it from app/.
- derive it from GtkScale not GtkRange so we get the keybindings again
- remove scroll_event() implementation, the parent class does the right
thing now
- remove lots of magic size calculation code about focus and borders
and whatnot
- instead, style its CSS nodes using a hardcoded CSS provider and simply
"know" the size of the slider in draw(), did this in code instead of
the theme CSS because we do pretty evil things here and we don't want
theme authors to think they can change much about it
Treat the gimp-core-pixbufs and gimp-icon-pixbufs resources like we
changed the cursor resources before, and clean out a lot of cruft from
icons/ (there is no need to generate stuff in all icon themes when we
include only one fallback icon from one theme).
Also remove all traces of it from the plug-in protocol and raise the
protocol version to 0x0100 (we now allow features and therefore
version bumps in stable, and the master protocol version should always
be higher). Fix the code that aborts plug-in startup on protocol
version mismatch, we can't use gimp_message() because we have no
protocol.
Add support for exponentiation (using the ^ operator) to eevl.
This is occasionally useful, e.g., in geometrically-derived
quantities involving square roots.
