Looking in these tests, most are hard to test with just the API. These
will need to be properly replaced once we'll make use of a UI testing
framework allowing such tests.
Issue #15763 is again mostly false positive crashes of the unit tests
because the code is only partly GIMP code, arranged differently as what
a full GIMP process would actually do.
The new tests just runs on the real GIMP code. Now the difference is
that we don't test the UI by doing this, but this can be debated whether
the previous tests were actually running on the UI themselves (they were
mostly running some core code directly and sometimes activating some
actions or raising dialogs (gimp_test_utils_create_image_from_dialog()),
but again not by actually clicking or hitting keys as a human would do.
It's not proper UI testing (cf. #9339 of #13376 for further discussions
on this topic).
So in the meantime, let's go with this intermediate step. At least now,
such tests would run actual GIMP code and would catch issues which could
really happen in a GIMP process.
Per review, let's avoid having all the tools history in every
GimpContext.
Also a further commit will work on special-casing filter tools, which is
why we are storing up to 3 tool infos, instead of only 2.
New action "Last Tool" ("context-tools-swap"), defaulted to <shift>X.
Thanks to Damien de Lemeny for the original patch and Alexander Hämmerle
for the test case in test-ui.c.
A GLogLevelFlags fatal_mask variable was
created inside an #if defined (G_OS_WIN32)
block, below a function call to
gimp_test_utils_set_gimp3_directory (). This
resulted in build warnings on Windows:
"ISO C90 forbids mixing declarations and code"
This patch adds another #if defined (G_OS_WIN32)
at the top and moves the variable declaration there.
While there are cases when you want to edit the mask straight away (this is
often the case when starting with a white or black mask), in many other cases,
the mask may be already as you want it per its initialization (e.g. when
initializing with a channel, selection, the alpha channel, etc.).
Until now, the Add Mask dialog was always switching to the "Edit Layer Mask"
mode by default, which forced an additional unneeded click each time you created
a mask (and were in a case where you initialize the mask as you want it
directly).
Now adding "Edit mask immediately" feature in the "Add Layer Mask dialog":
* It's checked by default to keep historical behavior.
* As most other dialogs, the last value is remembered, allowing people with
repetitive workflow not to have to repeatedly set the settings each and every
time.
* This default is also visible and settable in Preferences > Interface > Dialog
Defaults.
… the whole canvas while keeping aspect ratio of the source image.
The previous dimensions were not entirely "out of the blue" since they
were taken from the file, but very often dimensions from vector images
are kinda bogus (apart from aspect ratio, they don't mean much) anyway.
Now we will just fill the canvas box by default.
When changing the source file of an existing link layer though (through
Link Layer properties), the dimensions will be within the current layer
bounding box.
Also I realized that we need to also store the link width/height in the
XCF because the buffer width/height may not be right (in case a
transform matrix was applied). This commit therefore breaks XCF file
with link layers made in the last 2 days. Since we have not made even a
dev release, it's probably fine to do this and not bump the XCF version.
This commit was edited after GIMP 3.0, now that we have dedicated
support for loading vector images with GimpVectorLoadProcedure.
- By default, when loaded as GimpLinkLayer, vector images are loaded at
a size so that they are exactly contained in the image.
- When scaled with Scale Layer dialog, link layers of type vector are
re-loaded from the source file to always stay perfectly crisp.
From the horse's mouth:
"WARNING: appstream-glib is heavy maintenance mode, use appstream
instead"
Additionally, appstream-glib no longer conforms fully to the
appstream specification.
Some care is taken to taken to support both libappstream 1.0 as well
as libappstream 0.16.x to support stable distros.
We just agreed that there is no point in keeping these forever if they
have not been fixed for years. They only produce warnings and also they
likely won't work in Wayland anyway so they probably *can't* be fixed
without heavy updates.
Before the "fix" on 941fc000, everything was working fine, which
is a sign that it wasn't even being used. Also, after Jehan own
investigation and my tests, I confirmed that it isn't used anymore.
Two tests were consistently timing out before this change:
save-and-export and ui. The gdk_test_simulate_key documentation mentions that
gtk_test_widget_send_key is the right approach for most testing purposes.
With this change, save-and-export started working for me, whereas ui now fails
properly - investigating this failure was the original point of the change.
This is the only "language" from the list whose name is special and
should be localized at runtime, yet before we set any Preferences
language. It needs to be localized as the System Language itself which
will be run-dependant.
For instance, if your system is in French, it will be displayed as
"Langue système" but if you change your system to Korean, at next run,
it would show "시스템 언어". It is a per-run localization, independant
from the language selected in Preferences, and even less dependant from
build-time system language.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes#10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
...to path.
Changes the names of
gimp_vectors_* () API to
gimp_path[s]_* (). Renames related files
to [path] instead of [vectors], along with
relevant enums and functions.
This commit renames the GimpVectors
object to GimpPath in both app/core and
in libgimp. It also renames the files
to gimppath.[ch] and updates the relevant
build and translation files.
There are still outstanding gimp_vectors_* ()
functions on the app side that need to be renamed
in a subsequent commit.
...to paths.
Similar to d0bdbdfd, but covering the
app/core versions of the API instead of
libgimp. Changes the names of
gimp_image_*_vectors () API to
gimp_image_*_path[s] ().
Also renames some related functions such
as gimp_image_pick_path (). The next step
will be to rename the gimp_vectors_* () to
gimp_path_* ().
I'm moving the logic of choosing a correct default for width/height by adding an
"extract dimensions" callback in the procedure. The logic is that every vector
format out there should likely have metadata either for pixel dimensions or
physical dimensions, or at the very least for no-unit dimensions (ratio only).
Vector load procedures will have to implement only the extraction of such data
in a callback called by GIMP but not how to act upon them, so that we have a
common logic for all vector images.
I am implementing this callback first in the SVG plug-in, moving all the code
to extract dimensions (and improving it) in this callback.
Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement
it using the same code, but it looks to me like this is very useless for vector
formats to have a specific thumbnail procedure (unless it were to use very
specific metadata for faster result). This is vector data, just ask it directly
at the proper bounding box size.
We were skipping tests when there is no display, which is always the
case on Windows. However, these tests always showed as succeeded.
Unless you looked at the test log, you wouldn't noticed that most of
the tests weren't actually performed.
Exit these tests with the value GIMP_EXIT_TEST_SKIPPED instead of
EXIT_SUCCESS.
You are not supposed to use g_assert in tests because g_assert can be
disabled using -DG_DISABLE_ASSERT, which makes tests fail.
Instead let's use the recommended replacement g_assert_true. At this
time we are not bothering using more specific g_assert_* functions,
since there are plans to change our test suite.
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.
Due to GObject Introspection we can't have the last part of an
identifier start with a digit, since that part will be used in Python
as the identifier, and Python doesn't allow that to start with a digit.
e.g. GIMP_ROTATE_90 would be used in Python as
image.rotate(Gimp.RotationType.90)
To fix this we add DEGREES in front of the number, without a '_',
even though that looks ugly.
Since the recent changes, these 3 tests are not working:
- tools
- session-2-8-compatibility-multi-window
- session-2-8-compatibility-single-window
(the 2 latters were only working with xvfb anyway)
I could just dig further as I did a bit these last few days, and tweak more and
more the testing code. But I think our current unit-testing framework is just
non-reliable and for all these years, we have spent more time fixing the tests
than actually relying on them to tell us there is a bug in GIMP.
Furthermore creating new tests is so cumbersome that basically none do it.
I have a plan laid out in #9339 for a much better and more reliable unit testing
infrastructure, based on the GIMP executable itself and a very simple syntax to
create new test scenari (so that even non-developers should be able to create
them eventually). So until then, let's disable these tests and stop wasting
time.
Also get rid of various old references to menurc and don't install it anymore to
etc/ (neither the new shortcutsrc as it doesn't look like it brings much value
to do so).
Pre-GIMP-3.0 code logics would re-allocate several GimpMenuFactory or
GimpUIManager for no good reason. While it was still working with old GtkAction
code, with our new GAction-based code, we were ending up overriding an action
with a new version of the same action, while keeping reference to old actions.
This made for discrepancies of the enabled or visible state of actions.
The new code keeps singleton of some objects and references to already
registered GimpUIManager or GimpActionGroups objects and make sure no actions
with the same name are created twice.
The meson build had the tools tests disabled unlike the autotools build.
Since enabling them doesn't cause any problems, let's enable them for
meson too.
