- Apr 23, 2024
-
-
Cheesequake authored
-
-
Anders Jonsson authored
-
Bruno Lopes authored
Due to design, crossroad install everything in the same prefix. So, let's drop the pkg caching (.cache) and reuse ccache path inherited from .default.
-
Bruno Lopes authored
Let's figure out what job is running using the predefined GitLab variables.
-
-
Lloyd Konneker authored
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.
-
Bruno Lopes authored
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.
-
- Apr 22, 2024
-
-
Lloyd Konneker authored
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.
-
Bruno Lopes authored
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.
-
Jacob Boerema authored
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.
-
-
-
-
-
Bruno Lopes authored
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.
-
Lloyd Konneker authored
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.
-
Alx Sa authored
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.
-
- Apr 21, 2024
-
-
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`.
-
-
Bruno Lopes authored
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 Lopes authored
See also: Infrastructure/gimp-web-devel!46
-
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.
-
-
Also update the gimp.rc and delete the committed fileicon.ico now that gimp-data generates this file the same way as these PNG fileicon-s.
-
Attribute uap4:ShellNewFileName is meant as a template file to be copied when someone initiate the Shell "New" command (via the Explorer context menu).
-
Bruno Lopes authored
Most of the work in this commit is by @Jehan. These icons are used only by the .msix (MS Store) distribution of GIMP. Some legacy icons are used only by Windows 10 and need to have smaller logo than full image dimensions, so let's not use colorsvg2png. We just pass the dimensions to use by configuring variants of the same base script.
-
Bruno Lopes authored
The new dist job can produce two artifacts: a *.msixupload file ready for submission and/or a *.msixbundle only for testing. See the commit about the script for more details.
-
This makes possible to debug with DIA SDK, if wanted by the developer. Also, this is needed to create .appxsym files for MS Store debugging. Ideally meson should be able to install for us, but apparently it doesn't. See https://github.com/mesonbuild/meson/issues/12977
-
Bruno Lopes authored
Adds PowerShell script and proper manifest for making .msixupload (only for releases) and/or .msixbundle (always, for testing). As authorized by Jehan, 32-bit willn't be supported. The reasons are: 1. 32-bit is going to die when WIA plug-in is done. This can hurt reviews 2. 32-bit is being restricted in ARM64 version. This causes disparity 3. 32-bit is generating a big footprint. "This is bad for the environment" To be clear: we are discarding most of 32-bit artifact (see point 1) and what could not (TWAIN for x64 only, point 2) almost doubles .msix. There is one small circumstantial reason too: 4. 32-bit wouldn't have .pdb even after GCC 14 because bins have same name as x64, and MS don't allow multiarch debug symbols in the same .appxsym
-
Jacob Boerema authored
Both in our Debian and Windows deps the openjpeg dependency was missing, so let's add it back.
-
Jehan authored
Though it's not visible and could happily wait for after GIMP 3 release, this was annoying when grepping. Just did a quick cleanup. I also removed gimprc.common which is a forgotten remnant from the autotools build.
-
Alx Sa authored
Per Pippin, the only color model that can have double precision is RGB/A. Therefore, we need to switch all others to use float instead. This patch converts the HSV and HSVA double babl formats.
-
Bruno Lopes authored
As hinted in d09a2a6f We now use the word 'bundle' to signify "program files in the same prefix" (e.g. .appimage, .zip, .app). This is in line with our source and dev-docs (just take a search in the repo). So, appimage and windows scripts changed. The word 'package' normally means "program files distributed for install in the same prefix or not" (e.g. .deb, .msi, .dmg). This is in line with CMake naming of some commands, but meson prefers to call 'dist', which we use more. So, this partly reverts some things of !1171 and reinforce others for even more "rationality" in the overall build structure of GIMP.
-
- Apr 20, 2024
-
-
Bruno Lopes authored
-
Jehan authored
… since forever anyway! GIMP used to have a second export dialog, a generically generated one, appearing either before or after (depending on when gimp_export_image() was called) the custom export dialog implemented by the plug-in code. This has been hidden deep in code since forever (since version 2.8.0 in fact, I believe) and only kept hidden behind an environment variable "GIMP_INTERACTIVE_EXPORT". I don't think we'll ever revive this, so let's clean up. In fact, not one, but in worst case even 2 more dialogs were hidden behind this variable! The first dialog (confirm_save_dialog()) was a confirmation when the selected drawable was a layer mask or a channel (and not a layer). Most export code don't even seem to care about the selected drawables anymore anyway (cf. issue #7370), except with gimp_file_save() non-interactively (issue #8855), which is a real mess of inconsistency anyway. The second dialog (export_dialog()) was listing the various actions to do on a copy of the image to help the plug-in (e.g. merge layers/flatten image, etc.) and possibly give choices to some of these actions. Though there is definitely no reason to request this kind of thing anymore, especially for a short-lasting image copy, the list of action could still be interesting in the future, not as information of what is going to be done, but as information of the kind of data loss of the exported format. I could imagine we want to be able to reuse such information for generating types of data loss per format in the export dialog, in particular in the context of my long-term export workflow refactoring (from which resizing before export such as #2531 are part of, but the whole refactoring project is much wider). In the whole discussion of #5858, there will be the question on whether we don't want plug-ins to be directly given a "ready-to-use" image depending on capabilities they advertized in create_procedure().
-
Jehan authored
-