1. 28 Jan, 2018 29 commits
    • Ell's avatar
      app: use gimp_transform_polygon() in gimp_transform_resize_boundary() · 3c0787e4
      Ell authored
      ... so that the transformed boundary is properly clipped.
      Adjust the boundary-size algorithms to operate on arbitrary
      Avoid using gimp_matrix3_will_explode() in
      gimp_drawable_transform_buffer_affine() and falling back to
      cropping the result, and avoid setting the "clip-to-input" property
      of gegl:transform.  Neither of those in needed anymore.
      This effectively reverts the app/ part of commit
      768d0661.  The next commit revets
      the libgimpmath/ part.
    • Ell's avatar
      app: use gimp_transform_polygon() in GimpCanvasBoundary · 258e60f1
      Ell authored
      ... so that clipping is done properly.
    • Ell's avatar
      app: use gimp_transform_polygon() in GimpCanvasTransformGuides · 4626190a
      Ell authored
      Add a "clip" property to GimpCavnasTransformGuides.  When set, use
      gimp_transform_polygon() for transforming the guides and the
      bounding box, so that they're properly clipped.
      Add a corresponding "clip-guides" property to
      GimpToolTransformGrid, and set it to TRUE in GimpToolHandleGrid, so
      that the handle-transform tool's guides are clipped properly.
    • Ell's avatar
      app: use gimp_transform_polygon() in GimpCanvasTransformPreview · 99005733
      Ell authored
      ... so that clipping is done properly.
    • Ell's avatar
      app: add gimp_transform_polygon() · cc20cb41
      Ell authored
      gimp_transform_polygon() transforms an (open or closed) polygon by
      a GimpMatrix3, performing clipping to the near plane, to avoid
      erroneously transforming points behind the camera.
    • Ell's avatar
      configure.ac: require GEGL >= 0.3.29 · 7dfe81f1
      Ell authored
    • Jehan's avatar
      app: remove the "save your work and restart" advice on fatal errors. · ee6e981c
      Jehan authored
      This is obviously not possible anymore to do this manually so this step
      is bogus in a crash case. We keep this step for other (non-fatal)
      errors. We may add an automatic "attempt" to save in a backup file
      later, which may not work depending on how bad the crash is (which is
      why it will be done in a backup file, we don't want to corrupt saved
    • Piotr Drąg's avatar
      Update Polish translation · def98c59
      Piotr Drąg authored
    • Piotr Drąg's avatar
      Update POTFILES.in and POTFILES.skip · 0ac29c0b
      Piotr Drąg authored
    • Jehan's avatar
      app: add SIGABRT to be handled by gimp_fatal_error(). · 07e8ce36
      Jehan authored
      SIGABRT is definitely a fatal error, at least in GIMP context. It is
      used by g_assert() and more generally by abort().
      Actually I am a bit unsure about the difference of gimp_terminate() and
      gimp_fatal_error(). The former mostly depends on whether we used
      --debug-handlers or not, which reads "Enable non-fatal debugging signal
      handlers". But the way we handle them, the list of signals handled by
      gimp_terminate() seem to always end up fatal as well, anyway. So either
      we should *really* make them non-fatal (I could imagine that SIGTERM or
      SIGINT indeed could be better handled for instance), or we should just
      get rid of this terminate/fatal_error differentiation which seems
      totally artificial and non-existing in the current code.
    • Jehan's avatar
      app, tools: title capitalize the debug dialog titles. · fe3cf080
      Jehan authored
      Also rename it to "GIMP Debug" and "GIMP Crash Debug" for continuable
      errors and fatal errors respectively.
    • Jehan's avatar
    • Jehan's avatar
      app, tools: install the debug tools in libexec when appropriate. · b318694b
      Jehan authored
      AFAIK this means on all platforms but Win32 and macOS which would rather
      need relative path and therefore cannot make use of build-time
      LIBEXECDIR. Anyway on these platforms, leaving the binary in BINDIR is
      not likely to "pollute" too much as it would on Linux or BSD where
      people often use terminal.
    • Jehan's avatar
      app: make the backtrace GUI actually work on Win32. · 4e5a5dbb
      Jehan authored
      It was previously untested, hence as expected needed fixes. First I add
      our own exception handler using Win32 API SetUnhandledExceptionFilter().
      Second, I reorder things so that ExcHndlInit() is run after this setter,
      since they will be executed as a FILO and we need backtraces to be
      generated before our separate GUI runs. Last I run the backtrace GUI as
      async. No need to keep the main GIMP waiting since the traces have
      already been generated into a separate file.
      Also replace gtk_show_uri() by the implementation taken straight from
      our web-browser plug-in, since apparently gtk_show_uri() doesn't work in
      Windows (and probably not macOS either since I see we have a separate
      implementation for this platform as well). I would like to be able to
      use the PDB but can't because this code needs to be usable both within
      the main process and into a separate tool process. Ideally, this should
      just be a utils function which could be included without a problem.
    • Jehan's avatar
      app, tools: various fixes for Win32 build. · a3a4df95
      Jehan authored
      * Type pid_t is not cross-platform. Just use int instead, and convert it
        to respective type on each platform.
      * Get rid of several useless include which should have been removed a
        few commits ago, when I reimplemented the backtrace function.
      * Better handle the various macros in gimp_eek() (between G_OS_WIN32,
        HAVE_EXCHNDL and GIMP_CONSOLE_COMPILATION, but also no_interface and
        generate_backtrace options, that was a bit messy).
      * Make gimpdebug now always built, whatever the platform.
    • Jehan's avatar
    • Jehan's avatar
      pdb: oups! I previously edited a generated file. · a700b15e
      Jehan authored
      This is the PDB I had to edit instead of app/pdb/message-cmds.c which is
    • Jehan's avatar
      app, tools: add support for ExcHndl/DrMinGW for Win32 debugging. · ae3cd00f
      Jehan authored
      The feature already exists in our code and produces backtraces upon a
      crash into a file. The only difference is that we are now getting the
      file contents and showing it in our new debug dialog, so that it works
      similarly on all platform (and therefore making the debug info visible
      to people, otherwise they would never report, even though the data is
      The difference with gdb/lldb is that it doesn't allow backtraces at
      random points (for debugging non-fatal yet bad errors). Also the API has
      just 2 functions and in particular an ExcHndlInit() but no way to unload
      the feature. So we don't need the debugging page in Preferences because
      the switch option would not work. On Windows, the feature will be
      decided at build time only.
      Last point: the code is untested on Windows so far. I assume it would
      work, but there is at least one point I am unsure of: will ExcHndl have
      already generated the backtrace file when gimpdebug runs? If not, I will
      have to let gimp die first to be able to get the backtrace.
    • Jehan's avatar
    • Jehan's avatar
      app: add a debugging page in preferences. · 270730d5
      Jehan authored
      Move the backtracing settings there. This page may also be used later
      for auto-saving on crashes, as discussed in bug 792787, or similar
    • Jehan's avatar
      app: add lldb as backtrace-creator alternative to gdb. · 4ca31b05
      Jehan authored
      It seems that on some platforms (macOS in particular), this may be more
      common to have.
    • Jehan's avatar
      app: test G_OS_WIN32 rather than G_OS_UNIX for new backtrace feature. · eab961c9
      Jehan authored
      This is just a bit more consistent with existing code. Also build the
      gimpdebug tool only when GIMP_CONSOLE_COMPILATION is not set and run
      when --no-interface CLI option is not set since it is a GUI tool.
    • Jehan's avatar
      app: add a "generate-backtrace" preference in GimpCoreConfig. · f8411a3d
      Jehan authored
      This will determine whether to output backtrace in a GUI and is disabled
      by default on stable, and activated in dev builds. It is a bit redundant
      with --stack-trace-mode option CLI and will take priority when enabled
      since most people would run GIMP with a graphical interface anyway.
    • Jehan's avatar
      app, tools: add backtrace GUI for crashes as well. · beede171
      Jehan authored
      This was a bit harder since even though we handle fatal signals,
      allowing us to do any last action before GIMP crashes, it seems more
      memory allocation is not allowed at this time. So creating a dialog or
      simply getting the return output of gdb into the main process is not
      allowed. What I do instead is running a separate program (gimpdebug)
      which will take care of creating the new dialog and running a debugger.
      I still use GimpCriticalDialog code from this separate binary, while I
      continue to use this widget also within GIMP for non-fatal errors. The
      reason why we still want to use it within GIMP is that we can bundle
      several non-fatal errors and backtrace this way (fatal errors don't
      return anyway) and it's easier to do so when created from the main
    • Jehan's avatar
      app: reimplement gimp_get_stack_trace(). · bb88a2d5
      Jehan authored
      Don't use g_on_error_stack_trace() from glib anymore. It is
      over-complicated, using gdb in interactive mode and running command
      writing in the pipe input. Sometimes it even gets stuck and never
      return. This is useless since gdb even has a batch mode, to just run
      commands and exit directly. I just use this.
    • Jehan's avatar
      app: new error dialog to backtrace and encourage people to report bugs. · 9fdf3555
      Jehan authored
      GIMP will now try to get a backtrace (on Unix machines only for now,
      using g_on_error_stack_trace(); for Windows, we will likely have to look
      into DrMinGW).
      This is now applied to CRITICAL errors only, which usually means major
      bugs but are currently mostly hidden unless you run GIMP in terminal. We
      limit to 3 backtraces, because many CRITICAL typically get into domino
      effect and cause more CRITICALs (for instance when a g_return*_if_fail()
      returns too early).
    • Michael Natterer's avatar
      app: fix GimpToolCompass for one perfectly vertical line · 5da3bdb4
      Michael Natterer authored
      the angle arc and the small helper line were displayed on opposite
      sides of the first point. Now they are on the same side, just like for
      all other angles.
    • Michael Natterer's avatar
      Bug 792981 - Measure tool is measuring one pixel to the right of initial point · c71535b7
      Michael Natterer authored
      This reverts 2069496a for
      gimpmeasuretool.c, we can't use gimp_display_shell_get_line_status()
      here because the angle to show is *not* the angle as shown in the
      paint tools (between x1,y1 and x2,y2), it is determined by a possible
      third point.
      Also, the info window and the statusbar were using different
      coordintates to detemine the line length. This would have been easily
      fixable, but the wrong angle wasn't.
    • Dimitris Spingos's avatar
      Update Greek translation · da4f03b8
      Dimitris Spingos authored
  2. 27 Jan, 2018 11 commits
    • Inaki Larranaga Murgoitio's avatar
      Update Basque language · fb9709be
      Inaki Larranaga Murgoitio authored
    • Inaki Larranaga Murgoitio's avatar
      Update Basque language · de5712dd
      Inaki Larranaga Murgoitio authored
    • Inaki Larranaga Murgoitio's avatar
      Update Basque language · 58155f64
      Inaki Larranaga Murgoitio authored
    • Inaki Larranaga Murgoitio's avatar
      Update Basque language · 1493950d
      Inaki Larranaga Murgoitio authored
    • Inaki Larranaga Murgoitio's avatar
      Update Basque language · 78b71164
      Inaki Larranaga Murgoitio authored
    • Inaki Larranaga Murgoitio's avatar
      Update Basque language · fab7d6c9
      Inaki Larranaga Murgoitio authored
    • Ell's avatar
      app: port relevant transform tools to GimpGenericTransformTool · 442be726
      Ell authored
      Derive GimpUnifiedTransformTool, GimpPerspectiveTool, and
      GimpHandleTransformTool from GimpGenericTransformTool, eliminating
      their common logic.
      Remove gimp_transform_matrix_handles(), which is no longer used.
    • Ell's avatar
      app: port GimpHandleGrid from gimp_transform_matrix_handles() to ... · 0334595c
      Ell authored
      ... gimp_transform_matrix_generic()
      Replace the separate x/y coordinate arrays of GimpHandleGrid with
      GimpVector2 arrays, and use gimp_transform_matrix_generic(),
      instead of gimp_transform_matrix_handles(), when calculating the
      matrix.  When the resulting matrix is invalid, hide the guides.
    • Ell's avatar
      app: add show-guides property to GimpToolTransformGrid · 6a64f096
      Ell authored
      ... which can be used to control the guides' visibility.
      Will be used by the next commit, to hide the guides in
      GimpToolHandleGrid when the tranformation is invalid.
    • Ell's avatar
      app: add GimpGenericTransformTool · 4c71ee8e
      Ell authored
      A subclass of GimpTransformTool, to be used as a base class for
      transform tools that calculate their matrix based on 4 pairs of
      input/output points, and that display the transform matrix as their
      GUI (this includes the unified, perspective, and handle transform
      tools; the next commit ports them over to
      When the resulting matrix of the input/output mapping sends any of
      the output points to, or past, infinity, GimpGenericTransformTool
      sets GimpTransformTool::transform_valid to FALSE, and displays an
      appropriate message in the tool GUI, instead of showing the matrix.
    • Ell's avatar
      app: add transform_valid member to GimpTransformTool · 6d0190b7
      Ell authored
      ... which specifies whether the transform matrix is valid.
      Subclasses can then set this member to indicate that the current
      transformation is invalid (which can happen in the unified,
      perspective, and handle transform tools).  When the transform is
      invalid, GimpTransformTool doesn't apply it upon committing, and
      returns an error instead.
      This commit doesn't set the transform_valid member in any of the
      subclasses, so there's no effective change.  The next commit adds a
      GimpGenericTransformTool subclass, that will use the new member.