commands that work on multiple layers:
Raise Layer -> Raise Layers
Layer to Top -> Layers to Top
Lower Layer -> Lower Layers
Layer to Bottom -> Layers to Bottom
Also update the hint strings.
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.
Resolves#11018.
Currently, babl formats are saved as strings when
passed as params. However, indexed palettes do not
use a "standard" encoding string but are created from
palettes (with a custom format). This results in an
error when we attempt to recreate the babl format from
the custom string encoding, as it doesn't exist at that
point.
This patch mitigates the problem by converting the indexed
color to RGB/A 8-bit when used in params. In the future when
indexed mode supports different color spaces and higher
precision, we will need to remove the hard coding. For now,
it solves the immediate problem.
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.
In the main menu and layers dialog context menu it is called
`Text to Path`, let's use that same name in the text tool actions
instead of `Path from Text`.
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.
Not all layer mask menu commands and help texts were updated to reflect
that they work on multiple masks.
Updates
- Apply Layer Mask -> Apply Layer Masks
- Delete Layer Mask -> Delete Layer Masks
- Their text hints and the one for Disable Layer Masks
Updates the undo strings, even though these don't seem to be used
anymore? Looks like undo always picks the menu command now.
It had actually been made unnecessary by 1c81c426.
This will allow for the full removal of GimpCMYK from
the codebase as part of the color space invasion.
Adds code to copy any NDE filters when
importing an .xcf file as layers in an
existing project.
This also requires removing the check
for the layer being attached to an image,
which historically made sense because
filter effects were immediately merged
down. Now that filters can exist separately
the check is no longer required.
GimpSourceTools like Clone and Heal use GimpPaintTool's
code for determining if they can work on a pixel-locked
layer. This means that they can not set a locked layer as a
source even though that would not affect the locked layer's
pixels.
This patch adds an additional condition to GimpPaintTool, to
allow operations if the tool is a GimpSourceTool AND only
Ctrl is held down. This allows the layer to be set as a source
while preventing it from being drawn on.
Note that this isn't enough for F1 to work, but that is a separate
issue.
I think that for now one help-id for all the layer effects is enough,
until we get a more final UI.
lua-lgi now works with Lua 5.3 on Windows:
https://github.com/msys2/MINGW-packages/issues/21171
According to my tests, after installing lua53-lgi MSYS2 package,
lua5.3.exe tries to run the goat exercise (fails since the goat
uses different lua API). Anyway, lua5.1 isn't required per se.
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).
The OpenEXR plugin was specifically set
to throw an exception if a chroma image
(Y/BY/RY) image was loaded.
This patch removes the exception and loads
the luminance channel only as a grayscale image,
which is how Krita currently handles it.
Future work is needed to properly convert the
chroma channels to import as a RGB(A) image.
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(?).
Resolves#11702
In 2.10, the x/y label background on the Curves tool used
GtkStateType enums to get the widget's background color.
These enums were depreciated in GTK3, and during the
port the gdk_cairo_set_source_rgba() command was left
out. This resulted in the current line color being used instead,
making it hard to read the label in some instances.
This patch restores the Cairo color update command, using
the gridline color as an equivalent to the background color
from 2.10.
Resolves#7588
After the port to GTK3, the Filter dialogue's width started
to be affected the length of the image name. If the name
was very long, the filter dialogue would expand to fit it.
This patch encloses the image title label in a GtkScrolledWindow
with polices of EXTERNAL width and NEVER height. This ensures
there will not be a scrollbar, and the label will not influence the
width of the dialogue. A tooltip was added in case the user wants
to hover to see the full name.
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.
Jacob Boerema