See: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1670#note_2152565
This makes the NIGHTLY flatpak use the local GIMP source. This reduces the
internet usage and makes possible to generate .flatpak from every branch out
there, which turns the flatpak finally really useful to code development.
Of course, this makes impossible to run 'flatpak-builder NIGHTLY_manifest.json'
without cloning or downloading GIMP code, but this is not a regression since:
1) the NIGHTLY manifest is in-source to begin with, so same thing as our other
building methods (except macOS), which runs over the code they are stored
2) the chances of someone downloading partial source code (the NIGHTLY manifest
alone) so being unable to build are low since this file isn't too easy to find
3) even if someone do this and don't like, we are not violating flatpak building
pratices since this option exists to be used (and will be in NIGHTLY only)
Despite we not building gimp nightly on aarch64 we need to sync with beta.
So, this updates to LLVM/Clang 18, which fixes 'gexiv2' and 'poppler'
problems with deps on that arch. 'json-c' and 'luajit' were adjusted too
with the use of proper build options to fix errors.
As decided in #10922, 32-bit will be tolerated in 3.0 series because of TWAIN.
So, let's package only the bare minimum files to the 32-bit TWAIN plug-in work.
This reduces the final installation size by approximately 215MB.
It's a common pratice to tell the user what version is being installed
even if this is somewhat obvious (the user opened the installer, he
should know it). Many installers do this and Win MSIX installer too.
However, there is no sign in our Installer about what version is
being installed (the reused splash/intro image doesn't count because
it isn't always different at each micro or revision, and text is small).
---
To accomplish that feature, the Inno langs needed to be patched since
Inno actually forbidden to use that feature when we have a Welcome page.
https://groups.google.com/g/innosetup/c/w0sebw5YAeg
But 'UninstallAppFullTitle' from the following langs couldn't be patched:
- Japanese
- Lativian
There are two approaches regarding the icon for Windows installers .exe:
1) same icon as the app: this give more identity, but creates confusion if
you saved the installer in the same dir of the installed app shortcut.
This approach is also confusing in the task bar (e.g.: running GIMP
stable while installing GIMP unstable);
2) generic icon (e.g. a box, a cd) provided by the tool: more generic if
you downloaded two installers generated by the same tool (ours is Inno)
I choose a middle ground and created a icon with: the app icon and an
"installer" symbol (a package box), which conveys the best of two words.
This also fixes the Inno inborn bug of the unninstaller with install icon.
After running almost all the py plug-ins, I noticed that few py modules and
pkgs are used to justify the need of a slightly faster build time with .pyc.
In the actual bloated status (with all .pyc), lib/python* is about 260 MB big.
With the bare minimum .pyc after the tests above, python*/ is less than 90.
So, let's purge the .pyc at bundling time (I'm not reinventing the wheel,
Krita do this too), which reduces the .zip bundles (so the Inno and MSIX
installs) in 170MB, the Installer .exe in 45MB and MSIX download in 60MB.
---
Let's also disable any .pyc generation, since GIMP installed with Inno in the
system-wide (aka admin) mode or installed with MSIX both doesn't handle well:
py plug-ins work but have CLI errors, unlike Inno user-mode and .zip bundle.
Actually, the Language dialog is always displayed, which is not too good since:
1) This is inconsistent: the install mode dialog (to choose user or system)
appears before using the system lang automatically. Even if Inno fix this:
2) This is tiring: depending on the context, the user can see up to 5 dialogs:
SmartScreen (1) > Install mode (2) > installer lang (3) > dev warning (4)
> SetupMutex (5): https://groups.google.com/g/innosetup/c/bkRtnHz2ygg
3) This is redundant: even if only 2 and 3 are displayed, why 2? Inno will
auto select the sys lang, which the user understand to search GIMP for PC;
4) This is confusing: even the lang dialog message being clear, some users
genuinely conclude that the selection will carry over to GIMP install like
the old Adobe CS installer (#5515). !1628 makes more clear that not, but
reducing confusion even more is a welcome plus considering points above.
So, let's use 'ShowLanguageDialog=auto'. That option ensures that the dialog
will NOT appear if the sys lang have a translation present in the installer,
which matches what every program does and even installers like Inkscape one.
If the lang isn't included in the installer, the dialog WILL appear so the
user can choose one which he is more fluent, being is a nice middle ground.
This solves an old bug that makes Inno report GIMP as being almost 1.8GB,
which is not true (it's 1.3GB at most). That was probably caused by the
overuse of components intersections (e.g.: gs + gimp, py + deps), which
Inno does not handle well (sometimes it not even displayed the cmp size).
TWAIN component is still reporting a wrong size since it's a totally
different beast, it will be fixed later.
Following c6634d66 and 09d6402a
These files are too small and aren't reused so no point keeping them modular.
Also, with them inside .iss we reduce the clutter in the installer/ folder.
Despite that folder mysteriously not being mandatory on Linux
(the contents are different), on Windows (in PCs without MSYS2)
this is required by a warning. So, partially reverts c808d13b
The gimp.org main page was being used as the updates URL but the
downloads page is more direct, avoiding confusion with news or with
the stable big red button (remember: we also have dev installers).
Temporarily drops 'cfitsio' which started weeks ago to change its hash.
In my tests, after "fixing" the hash, sometimes it alternates to another,
which breaks the build again. This is too hard to maintain and unsafe(?).
Following e93e0f49
This defaults 'Segoe UI' for Installer texts and for license's body. This
font is still used as the default in Windows 11 and even in online docs.
We are also bumping to 9 pt as outlined in the final Win32 guidelines:
https://learn.microsoft.com/en-us/windows/win32/uxguide/vis-fonts
I've done microscopic pixel checks and confirmed that this produces a Win32
compliant design, which renders kerning and spacing equal as 'Win + R' and
UWP Notepad (please note that some "legacier" Win32 apps renders different)
---
Also, change from Lucida Console to 'Consolas' (default console font since
at least Win8). Today it is Cascadia Mono but not included with Win 10.
This makes the output more complete but at the same time less
polluted regarding the bundling scripts (base, deps and sym).
---
Also, packaging scripts (inno and msix) were touched as consequence
of experiments about drop bundling, for saving space (~20MB), of:
- etc/gtk (MSYS2 don't build immodules)
- share/ghostscript (macOS .dmg don't package it)
- share/libthai (macOS .dmg don't package it)
- share/locale (???, decided to kept only gtk and iso-codes to test)
- share/man (installer don't package it, maybe because Windows can't open)
- share/poppler (macOS .dmg don't package it)
- bin/bzip2.exe (???)
- bin/gdk-pixbuf-query-loaders.exe (loaders.cache already bundled)
- bin/gspawn*.exe. (???)
- share/gir-1.0 (installer don't package it)
- share/lua (???)
- share/vala (installer don't package it)
The "???" ones seems to not be used according to my local tests. If
they are, a bug will appear so we will be able to know, comment in
the script (for maximum clarity towards the future) then revert.
In the process, make the Installer localization process less 'masochist'
(in other words: less manual). The custom '.xml' was the only way since
the iso-codes, Dammed Lies and Inno namings don't match.
This reverts commit 085d8a02b5.
For some reason, Windows doesn't allow us to use that feature
(confirmed this after using the version from the Store itself,
not the .msixbundle)
The installer is probably the most complex packaging format so one of the
biggest examples of packaging love over the years into it in our repo.
But the readability of installer scripts... leave a lot to be desired.
Now, the main script is organized following the order of installer pages
with some comments. This will make easier to future contributors work
(but this commit probably isn't perfect since it's a big change to read)
We have counter measures to avoid installing while gimp opened at 'prep time',
but until now none for the installer itself. Let's fix it with SetupMutex.
The final UX is just less worse (than today): the user needs first to select a
language, then only after this the dialog about two installer will be prompt.
Seems that Inno devs willn't fix: https://github.com/jrsoftware/issrc/pull/461
Following 0199faac
We use arm64 runners for the installer job to avoid queues, but...
llvm-objcopy is well know to lack parity and one sympthom is the
'invalid SymbolTableIndex' warning when handling x86 debug symbols.
This commit just makes the installer display a (unchecked) checkbox, like Win
pkg manager (WinGet) so it's doesn't change the actual behavior. It also don't
break string freeze since the .isl string already exists and have translations.
The benefit to some users is having one less click to launch GIMP: [checkbox] >
[close]; instead of: [close] > [start menu icon] > [gimp in 'recommendations'].
Bruno