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.
… found at build-time.
It was working on a machine with default paths and system-installed
packages (e.g. a typical Linux distributions) but needs to be manually
set up e.g. on Windows.
In particular, we don't want the build to succeed when various obvious
issues occur, which may even end up in a successful-looking build (yet
with no proper language lists), like we had in !1597.
Unlike the GimpTranslationStore which can use a list of pre-localized
languages (each language in its own name), the GimpLanguageStore must be
displayed in the currently used locale.
Our GimpTranslationStore contains self-localized names of all languages
we support.
As for GimpLanguageStore, it contains all known languages with their
name in the current locale. When moving to ISO 639-3 list, we had all
possible language, included ancient ones, extinct ones, and so on. With
the iso-codes installation on my machine, this meant a struct with 7910
languages! When showing the Text tool options for the first time, GIMP's
UI is frozen for a few seconds because of this, while it constructs the
GimpLanguageEntry making use of the GimpLanguageStore.
By only listing part 1 and part 2 languages (as well as the rare
languages which are not in these list yet which we still support, i.e.
right now only 'ckb' (Central Kurdish), see #11626), the list lowers to
189 languages, which is still good and are the main languages or
language families AFAIU. And now the Text tool options are constructed
instantly.
Note that this is in fact even less than when we were just using
iso_639.xml (I counted 487 languages stored there), but I believe it to
be enough for the usage we have in the Text tool.
Instead of always parsing the ISO-639 listing at each and every startup,
let's just generate the list of languages, their English name, and the
self-localized names as static struct.
This will just be much faster, and no worrying on the size of the XML
(or json) to parse.
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.
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 commit is separate from the previous to make it immediately clear (by
comparing files) that the previous commit is a simple move with no modification
whatsoever of the icons/ directory, i.e. the symmetrical removal of add commit
gimp-data@8b54490.
We now clone gimp-data as a meson subproject. I am currently testing the
subproject feature though I am doubting a bit because of its limitations: the
git clone is not updated automatically, nor are errors clear. Therefore it would
be easy to end up with outdated data for developers not manually and regularly
running:
> meson subprojects update
Worse, it looks like even when updating the suproject, it fails to be properly
reconfigured. See: https://github.com/mesonbuild/meson/issues/12898
We pass 2 GeglColor through the wire now. Since it is passed very early
(when sharing the configuration), I had some issues with initialization
order of GEGL, and in particular when calling gegl_init() before
gegl_config() inside _gimp_config(), I had a bunch of such criticals:
> Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core'
Anyway in the end, I store the passed colors as raw bytes and strings in
the GPConfig object, and re-construct the GeglColor last minute in
_gimp_config().
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.
We use US English which uses behavior. So we replace all occurrences of
behaviour.
Most notable is File Open behavior in preferences. Besides that several
mentions in function documentation and a few in comments.
Per @Jehan, this solution would prevent default icons from being loaded
in custom themes if they did not include their own version.
The only thing kept from !909 is the replacement of hardcoded strings
in a few files with constants defined in gimpicons.h.
Five icons in the Layer dockable were being replaced by GTK defaults at
runtime. A "gimp-" prefix was added so that GIMP's version would always
be used. A few dialogues were fixed to use constants rather than
hardcoding the filename, to make it easier to update the icon in the
future.
Especially as our code does not actually leak as far as we can see. It looks
like librsvg might not play well with -fsanitize=address (possibly having real
leaks or false positives).
Cf. the previous commit: colorsvg2png has a memory leak in librsvg (so we can't
fix it easily). In any case, it's just a one-time-use tool, we don't really need
to focus on its memory bugs as long as it does its job to make icons.
Actually even with this, b_sanitize=address still detects a memory leak. After
some testing, it seems that just creating a RsvgHandle, then freeing it
immediately is enough to leak some data, which means the leak is in librsvg.
This will allow to also check the list of runtime builds. We could see an
example in a report (#8993) where someone had the latest flatpak build of GIMP
but an older build of the runtime flatpak. So they had a bug because of a
dependency which got updated since then.
- Setting an exec_dir variable is an error. As meson docs says, if
relative, it is installed relatively to prefix anyway: "If this is a
relative path, it is assumed to be relative to the prefix."
On the other hand, it would make problems if someone tried to set an
absolute bindir.
Moreover it is a lot clearer now. When we want to install in the
binary directory unconditionally, then get_option('bindir') is the
meson way, hence the way to go.
- On the other hand, the `gimp-debug-tool` is installed either in bindir
for Windows or macOS and libexecdir for all other platforms, at least
that's how it's set in the autotools build. So let's keep both builds
consistent.
- Make a hopefully clearer description for enable-default-bin option.
Let's clarify this is just about creating unversionning links pointing
to versionned files.
- Adding an item in the "Optional Features" part of the summary listing
during meson configure, for better discovery.
For the ".exe" extension on Windows, I wished we had an $(EXEEXT)
equivalent on meson rather than trying to set it ourselves (are there
other platforms where we must set a different extension?). But I could
not find any.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
Displaying it all the time when we fail the first attempt is confusing
as it is expected to fail in the meson build (since build libraries are
in different folders). Instead only output the error message when both
known paths failed, i.e. when we fail the script (and write down both
attempted path in the error message).
The check script now takes into account both the autotools and meson
file hierarchy (in autotools, built libs are in .libs/ subdirs).
Also it now properly fails on missing lib.
Since we are pre-processing anyway the AppStream metadata file (because
appstream-glib doesn't pass unknown XML attributes, cf. a previous
commit), it does feel silly now to continue loading the file at runtime
too. Let's just pre-process more data into the constructed C files, i.e.
get the introduction paragraphs and the change items too.
The only other remaining advantage of appstream-glib was that it was
handling the localization but since we also have these localized strings
in our gettext files, we can as well translate with gettext as any other
strings and it works just fine.
It will also get rid of any packaging issue, forgetting to package the
metadata file (as we had on the Windows installer, and still have on the
macOS package). Now it will just always work because data is internal.
The idea is to add some "demo" attribute to a list item inside the
<release> tag, since we already decided that (for now at least) we'd
keep a strict "intro + list" logics, as we did until now.
This demo attribute uses an internal format to specify successive
widgets to blink (like a demo path towards a feature). For now, what it
allows is:
* raise the toolbox, select a tool and blink the tool button.
* raise a dockable, blink any widgets in there.
Now it is still limited and needs to evolve. In particular:
* What happens if the blinked tool button was explicitly removed from
Preferences? Should we re-add it for the demo? And once done, should
we remove it again? Then should we select back the tool previously
selected?
* What happens if the dockable widget is not visible? Should we allow
changing the settings to be able to demo correctly the new/changed
settings? Should it be temporary? If temporary, it can be annoying as
you'd still have to look attentively the demo to find back the path to
the new settings. If not temporary, some people may dislike we touch
their settings.
* What if docks are hidden? Should we unhide them, then hide them back
after demo time?
Also regarding the implementation: originally I wanted to just grab the
demo attribute directly from the AppStream metadata file, but I realized
that appstream-glib cleans out unknown attribute from the XML. I could
then simply parse the file with a generic XML parser, but I found
simpler to pre-parse it into a header built within GIMP. I still use
appstream-glib at runtime as it takes care of localization for us
(though in the same time, we also have the localization in the main po
files, so maybe we could just embed the release note strings as well).
See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
Makes more sense and I am trying to make the devel-docs more readable
(which includes less crowded, especially with scripts which are not
really docs).
Jehan