This should hopefully fix:
> realpath: /Users/circleci/macports-gimp3-arm64/var/macports/build/_Users_circleci_project_ports_graphics_gimp3/gimp3/work/build/.GIMP3-build-config-: No such file or directory
Though it's harder to verify because of the "Intel macOS resource brownouts"
going on on CircleCI infra, and only x86_64 runners allowed me to SSH to them.
But I think that's the right fix seeing the error.
The preview widget is a bit stretched, though at least I fix the contents to be
distorted (instead, the preview is fine but we've got black-filled parts
around). I'm not focusing on it because anyway, I'm not sure either if the
preview is that important, or (if it is) whether we should not just integrate it
as part of GimpVectorLoadProcedureDialog, i.e. for every vector images.
For our two "development" sub-stages, the expiration is as follows:
The 'dependencies' stage artifacts continues to expire in 2 hours.
Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo).
For "stage"/tests and "production"/dist, the expire time depends
on the source of the CI pipeline. If the artifact is oriented to a
'short-span' source (e.g. MRs and commits), it expires in 2 days.
If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days
(we choose 8 to have a +1 day artifact just in case if something
goes wrong in the weekly schedule day, which isn't rare actually).
This happens in particular for in-build runs (or when using
GIMP3_DIRECTORY environment variable on an empty directory). In any
case, I don't see why we wouldn't try and create a directory which was
configured for data storage.
We compile GObject-Introspection anyway (except for cross-builds, where
anyway we don't rely on local Python scripts), so even if not installing
the Python plug-ins, still use them locally.
Resolves#11176
After the initial color space invasion, changing colors in the IFS color
transformation section no longer affected the image. It seems that
ifsD->*_cmap->color held the actual color selected by the user, but
this value was not making it into elements[ifsD->current_element]->v.*_color.
This patch connects the *_cmap->color values to the functions used
to draw the image on the screen.
Move test plugins from /scripts to /scripts/test.
POTFILES.skip that directory.
Add a readme to scripts dir.
Revise readme in scripts/test
Rename test9.scm which tests the new byte type support in Scheme.
Install it in unstable build, it is an important test,
long and sophisticated.
Install contactsheet.scm as a test plugin in unstable build.
See test/meson.build for comments about its issue.
Formerly, both Clothify and "Clothify v3" are installed
in menu Filters>Artistic.
They are duplicates.
Clothify is the original using the old-style, homegrown interface.
"Clothify v3" is new-style, GimpProcedureDialog interface.
Both are marked for translation.
Only Clothify (v2) is translated (in potfiles.in)
"Clothify v3" is not translated (in potfiles.skip)
This commit does not break string freeze.
Moves "Clothify v3" to Demos menu.
It only installs in an unstable build.
The new is installed in unstable only for comparison with the old.
FUTURE: when no string freeze:
Swap the new and the old.
Move "Clothify v3" clothify-v3.scm to potfiles.in
and move "Clothify" clothify.scm to potfiles.skip.
Swap the menu items, so the user doesn't see "v3."
- Fix a few broken references and an inconsistent argument name.
- Add the new headers in the introspectable header list.
- Add a few missing class descriptions for GimpProcedure and subclasses.
Instead of filling default GUI for a specific type of plug-in procedure in
fill_list(), we add 2 methods:
* fill_start() is ensured to run once (and only once) before any fill_list()
code runs.
* fill_end() is ensured to run once (and only once) after all fill_list() ran.
This takes care of 2 kind of GUI bugs which we could have:
1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill()
nor gimp_procedure_dialog_fill_list() were ever run), then the default
interface would not be added to the dialog. Yet this case could happen when
we don't want anything else but the default GUI (this will be the case in the
upcoming file-wmf-load GUI).
2. Second if at the opposite, you fill several times fill functions (I hadn't
thought of this, but noticed some already started to do this in our ported
plug-ins), we obviously don't want the default GUI to be added several times
either.
As expected, it is made to reuse shared code for every GimpVectorLoadProcedure.
In particular, they all need to choose dimensions to load at, so we are sharing
a same GimpResolutionEntry widget logic everywhere now.
I am in fact still very unsure about the code logic for this widget by the way
for these reasons:
* It still puts too much emphasis on the "resolution" (pixel density) part,
which makes people believe it's important, while they should in fact choose
the pixel dimensions most of the time and not care about the pixel density.
* Right now we can't break ratio (which in fact was already impossible in most
vector format plug-ins we had). Do we want to add a chain and allow this?
* If we consider the pixel density as the one we want to set the document with
(which may not be the same thing as the one from when we load the document),
we also want to break link between width/height dimensions and pixel density.
Right now we can't (updating one field updates the others too).
* There is always this issue of precision with pixel density vs. pixel
dimensions because we don't necessarily find the same values when computing
from one side to another because of lack of precision and this confuses
people.
* Finally there is the question of multi-page documents (e.g. PDF) where the
chosen dimensions are the document dimensions whereas each page may have a
different size which has to be recomputed independently and this got me
off-by-one errors. I think I'll need to review a bit the logic, but I'll do
once I've ported all the vector format load plug-ins first to see the most
common usages.
The code comes from plug-ins/common/file-pdf-load.c and apparently it used to be
in libgimpwidgets (very long ago). I'm copying it to its own file and massively
improve the code (depending on property binding which makes the behavior much
more robust).
Still I left it as private because I don't want to say the API is finale without
having tested it a bit more. But eventually we should make it public for
plug-ins to use it directly too. When this happens, it should get back to
libgimpwidgets.
It's still basic but will help to share code for support of various vector-able
formats, such as the logic for dimensioning them, but also the generated GUI.
Not only this, but we are paving the way for the link layers (though it'll be
after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way
for a plug-in procedure to advertize a vector format support. This way, the core
will know when a source file is vector and can be directly reloaded at any
target size (right now, in my MR for link layers, the list of "vector" formats
is hardcoded, which is not reliable).
Only affects unstable build.
Move remaining items to Demos.
They have names like "Test foo."
They only install on an unstable build.
The ScriptFu>Test menu is only in an unstable release.
It is untranslated.
The ScriptFu menus don't need to be so deep.
The Demos menu is an appropriate place for test plugins.
If the Demos menu is not in the stable release and translated,
Gimp creates the Demos menu and it is untranslated.
The "Sphere" plugin demonstrate all the widgets for arguments of a plugin.
Only its menu label is translated.
The "Hello World" plugin demonstrates an independently interpreted SF plugin.
It has no translations, even of its menu label.
Formerly in ..ScriptFu>Test menu.
They still are installed even in a stable release.
If we don't want 3.0 stable to ship with demos,
need more changes to meson.build.
They are akin to the goat exercise plugins.
These plugins are expected to ship with the goat plugins in a stable build.
!!! But 2.10 did not ship with any demo plugins in stable build.
There are duplicate "Sphere" (v2) and "Sphere v3" plugins.
Does not break string freeze.
The new-style "Sphere v3" plugin moves to Demos.
It will be installed with stable build.
No translations will change.
"Sphere" (v2) will only be installed in an unstable build.
FUTURE: we should translate Hello World and Sphere v3.
If they are to ship as demos, their GUI should be translated.
FUTURE: low priority we could rename "Sphere v3" to just Sphere,
and Sphere to "Sphere v2" so there is no conflict.
Partially reverts af79bbe0 (regarding .debug "extraction" in cross builds)
Now, we call the split debug script from the main bundling script, which makes
similar to our macOS .app bundling script. This cleans a bit of code in .yml
and make things clearer to the mere mortals in the scripts.
Its contents is a test plugin, "Test dialog".
I am responsible for it, and it is ugly, even in unstable.
Is only installed in an unstable build.
We need a convention that menu items for plugins named like "Test foo"
should only be installed in unstable build,
and should require no translations.
Note that if the Demos menu does not exist,
Gimp creates it, and it is not translated,
but only present in an unstable build.
Native arm64 and x64 TWAIN binaries are not built anymore. No need to
discard at dist time what doesn't exist. (32-bit TWAIN not affected)
Also, start to using our own ARM64 runners to do the dist. This is more
reliable since the shared x64 runners can (and indeed) cause long queue.
When there is a very long comment shown in the export dialog, the
dialog expands horizontally. Possibly making it wider than your screen
instead of wrapping the text.
Let's set word wrapping for the text view. That way the text will
wrap at a reasonable length and use the multiline text view instead
of just the first line.
They were generating a distracting output in CLANG* shells, as noted by
@lillolollo in a comment from MR: Infrastructure/gimp-web-devel!65
In the process, make AppImage and Windows (native) scripts use these
variables, without hardcoding the same variables from .yml anymore.
Fix ScriptFu, CRITICAL handling filename args user-entered in old-style interface.
Fix plugin, changes to API re Resource i.e. Palette and Colormap
Add message giving mangled name of output file.
Driveby minor refactoring of plugin.
Driveby cleanup, remove old email addresses.
Driveby use script-fu-use-v3 binding to PDB.
Resolves#10914
Some dockables such as "gimp-pattern-editor" and
"gimp-mybrush-editor" are listed as Editors even though
we don't yet have dedicated GimpDataEditors for them.
This causes problems when using certain features like
duplicating. To resolve for now, we check if
gimp_window_strategy_show_dockable_dialog () returns a
valid GimpDataEditor before trying to use it.
Per Jehan, we also verify that an edit button exists
and is visible before we try to call the edit command.
Creating a temporary config directory for the in-build GIMP (run as a tool or
for unit-testing) is not done as a build target anymore, but in the
in-build-gimp.sh script as a unique temp directory, then cleaned out on exit.
This has a few advantages:
- It is properly cleaned out once the build ends (instead of leaving a full
config dir as trash inside the build dir).
- It is not reused from one build to another (with risk of carrying bugs and
issues over).
- Every use of the in-build GIMP will have its own config directory, and in
particular when they are called in parallel.
As a side update, make sure that all `gimp_exe` runs depend on
`gimp_exe_depends`.
This is recommended by Microsoft for "*nix apps" and adding it to the
.exe manifest will avoid disparity between MSIX and other versions
(e.g. CI crossbuilds and CI native builds/installer/local builds).
Bruno note: This commit was repurposed after ad132ad0.
---
For some reason, on the Windows/Aarch64 runners only, submodule updates fails
with:
> + git submodule update --init
> From https://gitlab.gnome.org/GNOME/gimp-data
> * branch d1041a4d97871c85538938872d0ace69d2fc44c2 -> FETCH_HEAD
> error: Your local changes to the following files would be overwritten by checkout:
> images/README.md
> images/logo/meson.build
> images/meson.build
The big question was: why are there edits to begin with? This is supposed to be
a brand new clone!
After a bit of investigation, it turns out that the whole files have incorrect
EOL endings (a `git diff` returns every possible lines in the whole
repositories, but `git diff --ignore-cr-at-eol` returns nothing). It looks like
this breaks the submodule update.
Jehan