1. 13 Oct, 2020 1 commit
  2. 12 Oct, 2020 2 commits
    • Jehan's avatar
      meson, autotools, CI: simplify plug-in binding build options. · e77d9517
      Jehan authored
      For Python, Lua and Javascript, make the option boolean (with 'yes'
      being the default). No need of a warning when not installing the
      plug-ins as this would have been disabled explicitly anyway. When
      installing the plug-ins, only make interpreter checks as precautionnary
      verifications which don't actually change anything (except outputting
      some warnings if interpreters are not found). Basically for these 3
      bindings, the interpreters are only runtime dependencies anyway. So it
      doesn't matter if they are not available at build time. In particular,
      we get rid of the 'force' option.
      
      Vala rules do not change as the vala compiler is indeed needed at build
      time and current checks work correctly. I just add a "Vala plug-ins"
      line in the summary message of the meson configuration, as it was
      missing.
      e77d9517
    • Jordi Mas's avatar
      Update Catalan translation · 47663730
      Jordi Mas authored
      47663730
  3. 11 Oct, 2020 1 commit
  4. 10 Oct, 2020 3 commits
  5. 09 Oct, 2020 8 commits
    • Jehan's avatar
      app: fix wrong extension active state on exit. · 3e0be204
      Jehan authored
      First the deserialize data of extensionrc was wrong. I need to edit the
      pointer to the GList (and dereference it when I need).
      
      Also when inserting an extension into the `running_extensions` hash
      table, I could not reuse the same string as in the `processed` list
      (because this string is going to be freed at end of initialization).
      Just always use the GimpObject name of the extension, since it will stay
      alive for as long as the object is alive.
      3e0be204
    • Jehan's avatar
      app: check extensionrc existence before trying to parse it. · 9c4860b3
      Jehan authored
      On first run, it would not exist (which is normal) which was producing
      an error message on stderr.
      9c4860b3
    • Jehan's avatar
      app: don't show an uninstall button for system extensions. · 91565715
      Jehan authored
      Unlike user extensions, system ones can only be deactivated, not
      uninstalled.
      91565715
    • Jehan's avatar
      plug-ins, extension: goat-exercises becomes a GIMP extension. · ecbc38f9
      Jehan authored
      This is an extension containing a few demo plug-ins. This is good to
      demonstrate the extension format. It will also allow to disable these
      plug-ins (if at some point, one doesn't want to show these demo
      plug-ins anymore).
      
      And finally it deals with the fact that our plug-in code is stupid, as
      it just tries to find the first executable with the same name (minus
      extension) as the plug-in folder. This doesn't go well on Windows, where
      the permission system is non-existent. So our code just ends up trying
      to run the first file with a similar name in a plug-in folder. As the C
      goat-exercise contains both an exe and the C source (and the system
      probably returns files in alphabetic order), GIMP under Windows tries to
      run the C source instead of the executable (this obviously doesn't go
      well).
      We could try to do more complex logics, like not aborting if the first
      file run fails and try the next one in the plug-in folder. Or maybe just
      rename the C file to another name. But any of these is just in the end
      the proof that our plug-in discovery right now is just bogus. The
      extension system is explicit, not based on randomly trying out files.
      Plug-ins entry points are explicitly listed in the metadata manifest.
      ecbc38f9
    • Dušan Kazik's avatar
      Update Slovak translation · 45fb76be
      Dušan Kazik authored
      (cherry picked from commit 1b2f58f8)
      45fb76be
    • Dušan Kazik's avatar
      Update Slovak translation · 14e1d802
      Dušan Kazik authored
      (cherry picked from commit 5551428d)
      14e1d802
    • Dušan Kazik's avatar
      Update Slovak translation · db37b1b1
      Dušan Kazik authored
      (cherry picked from commit 46a12d4a)
      db37b1b1
    • Dušan Kazik's avatar
      Add Slovak translation · f106c231
      Dušan Kazik authored
      (cherry picked from commit 781d5bce)
      f106c231
  6. 08 Oct, 2020 4 commits
  7. 07 Oct, 2020 1 commit
  8. 04 Oct, 2020 2 commits
    • Yuri Chornoivan's avatar
      Update Ukrainian translation · 45ad1c0b
      Yuri Chornoivan authored
      45ad1c0b
    • Jehan's avatar
      plug-ins: change export dialog title when exporting as AVIF. · 5ec3293f
      Jehan authored
      Even though "Export Image as HEIF" is not technically wrong (AVIF is AV1
      encoding inside HEIF container), it is better to be more accurate.
      
      Moreover as Daniel Novomesky was explaining in a MR, nowadays when we
      say "HEIF", we usually mean "HEIC", whereas you'd use the explicit
      "AVIF" naming for HEIF/AV1 images. This seems confirmed by Wikipedia
      which says that HEIC is the "implied default codec for HEIF".
      
      So let's just make the AVIF vs HEIF distinction here (I could have used
      AVIF vs. HEIC which is even more explicit but I decided to keep the
      less-specific yet more used HEIF naming).
      5ec3293f
  9. 03 Oct, 2020 2 commits
    • Jehan's avatar
      gitlab-ci: name the distribution artifacts and small build-deps.sh fix. · 6f4155ee
      Jehan authored
      This should give a nice name to distribution archives so that they are
      not all called `artifacts.zip`. Names will better describe their
      contents (target OS or source and short commit hash, because for CI
      builds, it's important to know which commit is being tested).
      
      Also replace CI_COMMIT_REF_NAME in other artifact names by
      CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in
      branch names), only the part after the last slash is used for archive
      naming.
      
      Finally immediately exits from dependency build with error code (!= 0)
      if `crossroad install` command failed.
      6f4155ee
    • Jehan's avatar
      42e25e5b
  10. 02 Oct, 2020 3 commits
    • Jehan's avatar
      build: (Windows) glib-compile-schemas and gdk-pixbuf-query-loaders in… · 6eab32c7
      Jehan authored
      … the CI.
      There are 2 finale steps before finale binary distribution on Windows.
      We must compile the GSettings XML schema files and register GdkPixbuf
      loaders (for file format support in the GUI).
      
      I used to provide a wrapper to be run inside Windows before first GIMP
      run. Never did I realize that I can compile the distributed GSettings
      schemas with the native `glib-compile-schemas` (works fine in my tests).
      As for the GdkPixbuf loaders, we inspect DLL libraries, hence we do
      require the target `gdk-pixbuf-query-loaders` which is unfortunately a
      Windows executable. Yet it seems to work fine with Wine, so let's be
      done with it in the CI instead of requiring manual steps from testers of
      the CI builds. Then a few `sed` calls are enough to make the path in the
      produced text file relative instead of absolute (which works fine, again
      in my tests at least).
      
      This means that I don't have to distribute the 2 binaries and the DLLs
      they depend on anymore. Moreover let's remove the wrapper (but still
      generate one which just calls GIMP so that we call it from the tree
      root, where it's much less messy).
      
      Note: I failed to install wine32 (32-bit Wine) on the Gitlab runner.
      After following all instructions, I encountered weird errors. So
      instead, I just make the win32-nightly job depend on win64-nightly and
      copy `loaders.cache` from one to another, as it is a
      platform-independent text file (as long as we provide the same GdkPixbuf
      loaders on both of course, which we do).
      6eab32c7
    • Jehan's avatar
      build: dll_link.py improved to handle both i686 and x86-64 Windows… · cdb61d82
      Jehan authored
      … executable formats inspection.
      cdb61d82
    • Jehan's avatar
      gitlab, build: Win32 distribution jobs for our CI. · 8f8f7e49
      Jehan authored
      The main purpose of these jobs is to only package the strict necessary
      for a working GIMP under Windows, i.e. getting rid of all unnecessary
      executables, and inspecting binary dependencies recursively to only
      package used DLLs.
      
      The dll_link.py script is taken from Siril codebase (see commit a86e82a8
      on Siril repository, by FlorianBen). This was a very nice idea, and
      makes for much smaller test archive (Siril is also GPLv3 so licensing is
      ok for the reuse, also anyway it's just a small independent build
      script).
      Moreover having it as a separate job allows to have artifacts with only
      the finale distribution (artifacts on the build job also have the build
      directory and the whole prefix, which we want to keep in order to debug
      when needed).
      
      Hopefully I am not missing anything. Siril seems to package more, like
      various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if
      these are actually necessary. I could run GIMP fine without these in
      quick tests, but I guess I'll have to investigate a bit more to figure
      this out. That's what nightly builds are for, after all, so hopefully
      people will report if we miss some runtime dependencies.
      8f8f7e49
  11. 29 Sep, 2020 1 commit
    • Jehan's avatar
      libgimpwidgets: GtkComboBox "active" property must trigger… · b326b68b
      Jehan authored
      … GimpIntComboBox "value" property.
      For this, I connect to the "changed" signal, which is equivalent anyway.
      Otherwise the link was not bidirectionnal, so selecting a new item in
      the combo list was not actually changing the internal value, hence the
      binding set by gimp_prop_int_combo_box_new() was not complete either.
      Not sure how I missed that. Hopefully not missing anything else!
      b326b68b
  12. 27 Sep, 2020 4 commits
    • Jehan's avatar
      etc: smaller default position and size of main image window. · b5298d06
      Jehan authored
      Existing default was requesting a window of size 1024×768 at position
      (200,100). While it may seem a reasonable default on nowadays displays,
      it was not on some intermediate size displays which are considered HiPPI
      anyway.
      
      Taking my personal example, my screen is 2560×1440, which is considered
      HiPPI by GNOME 3 with a scale ratio of ×2. As a consequence, setting a
      size of 1024×768 was actually creating a window of 2048×1536, which is
      already higher than the screen. Worse, gtk_window_resize() resize the
      window without taking into consideration the title bar, which in my case
      added 74 pixels, so GIMP window started at 1610 pixels of height, much
      bigger than my screen size, hence unusable (and for some reason, with
      the title bar out of the screen so without knowing Super+click shortcut
      to move or Super+Up to maximize, people would have a hard time to resize
      or close GIMP).
      
      This issue only happens at the first launch of GIMP, when no user
      sessionrc exists yet. Once you resize yourself the main window, then
      restart GIMP, it is fine (as next times, it will use the user's
      sessionrc). Yet it is already a bad first impression.
      
      For temporary workaround, let's use a smaller 800×600 defaults (which
      will actually span on 1600×1200 pixels + decoration size on scale ratio
      ×2).
      
      Still I don't like using arbitrary numbers for window size default.
      As we see here, it can end up into all sort of weird result. Even more
      with all the scale ratio business which didn't exist back in GTK+2.
      Instead, the defaults should have no size, and our code should just
      resize to whatever makes the most sense on the current display, which I
      believe should likely be maximized. Unfortunately I have a hard time
      with gtk_window_maximize() which doesn't seem to do anything at all
      (does GNOME ignore _NET_WM_STATE_MAXIMIZE_* hints when requested by
      applications maybe?). So until we find the right system, let's go with
      this lower window size defaults at least.
      b5298d06
    • Jehan's avatar
      icons: (meson) gimp-curve-point-* icons were not installed for the… · 68e04635
      Jehan authored
      … Symbolic theme.
      It was installed for the Color theme, but not the Symbolic one with the
      meson build.
      68e04635
    • Jehan's avatar
      NEWS: update with some of the master-only changes. · 7fb2fb93
      Jehan authored
      As it involves some API changes and code moved from libgimp to core, I
      just won't backport all the new rotation policy logics in gimp-2-10
      branch. I could have cooked something up, at least to have new settings
      in Preferences for updating the rotation policy (currently it's
      implemented as a global parasite which is quite bad as it makes the
      settings virtually non-updatable in a sane way) but really I don't want
      to spend too much time on this. So let's just say it's GIMP 3
      improvements.
      7fb2fb93
    • Sebastian Rasmussen's avatar
  13. 26 Sep, 2020 7 commits
    • Liam Quin (ankh)'s avatar
      plug-ins: The plugin can leak the "tif" file descriptor as written... · fe340c82
      Liam Quin (ankh) authored
      ... and also doesn't write out all the data, if it does a "goto out" for
      any reason. A leaked file descriptor can prevent a file from being
      renamed or deleted on Windows.
      See also #3740.
      
      Reviewer note (Jehan): this may not be the main issue as reporters were
      not writing about export failure. So there is probably another case even
      when the plug-in successfully wrote the TIFF image.
      fe340c82
    • Jehan's avatar
      gitlab: update Container Registry link. · 9f385b28
      Jehan authored
      Apparently the docs changed so the anchor is broken (and contributors
      are confused). Also the docs now says that Container Registry is enabled
      by default. I assume this must be a recent change which is not available
      yet in GNOME's Gitlab instance. So we must ask people to do the opposite
      of what the docs says.
      9f385b28
    • Jacob Boerema's avatar
      fix: themes_theme_change_notify: error parsing theme.css on Windows. · 9acefd22
      Jacob Boerema authored
      When loading a theme on Windows we always get an error like:
      themes_theme_change_notify: error parsing [path including drive letter to:]\theme.css: theme.css:8:99Failed to import: Operation not supported
      
      The location points to the end of the filename of the first @ import url string.
      This is caused by the string not being an url.
      Based on suggestions from Jehan and lillolollo we replace g_file_get_path
      with g_file_get_uri since an url is what is expected here.
      Since that function already escapes the string we also remove
      g_str_escape here.
      9acefd22
    • Rico Tzschichholz's avatar
      9c90ab44
    • Jehan's avatar
      libgimp: 'gimp_ui' as priority prefix for GimpUi introspected module. · 2e73e30a
      Jehan authored
      Since meson 0.43.0 (below our current requirement), 'symbol_prefix'
      argument of gnome.generate_gir() allows an ordered list. If I prepend
      'gimp_ui', it makes any gimp_ui_*() function to not start with 'ui_'.
      
      In particular, GimpUi.ui_init() becomes GimpUi.init() which is much less
      redundant.
      2e73e30a
    • Yacine Bouklif's avatar
      Update Kabyle translation · aac49878
      Yacine Bouklif authored
      aac49878
    • Jehan's avatar
      app: GimpFilterTool displays a "Sample merged" checkbox. · 578c0785
      Jehan authored
      In several GeglOperation filters, it is possible to pick a color. Up to
      now, it was only possible to pick a color from the active layer (the one
      you run the operation on). With this change, we can also pick in Sample
      merged mode, same as Color Picker tool and other color tools.
      578c0785
  14. 25 Sep, 2020 1 commit
    • Jehan's avatar
      Issue #5630: Sample Merged as defaults in Color Picker tool. · 578e3b0b
      Jehan authored
      The rational: advanced users won't really care about defaults (they know
      to switch this option on/off depending on situation) but maybe beginners
      would be less confused to pick "what they see" on first use, rather than
      picking on the active layer? Now whatever is the default won't change
      anyone's daily usage of GIMP. Clearly every image and use case is
      different, so both with or without sample merged are useful one time or
      another (this is why the option exists). It's really about the less
      surprising option for beginners, based on usage statistics.
      
      I ran a small poll on Twitter/Reddit/Patreon/Tipeee and ended up with
      numbers of 131 for switching to "Sample merged" as default and 43
      against, which is about 75% in favor. So let's just switch. It makes
      sense anyway.
      578e3b0b