1. 15 Feb, 2018 2 commits
  2. 14 Feb, 2018 3 commits
  3. 13 Feb, 2018 9 commits
    • Ell's avatar
      app: small cleanup in xcf_load_channel_props() · fcde7bdf
      Ell authored
      Remove the impromptu boundary invalidation when converting a
      channel to a selection mask in xcf_load_channel_props(), as this
      happens implicitly when stealing the channel's buffer, since
      commit 38d4aa81.
    • Ell's avatar
      app: use gimp_drawable_steal_buffer() in gimp_text_layer_from_layer() · 3b8e1ebe
      Ell authored
      When constructing a text layer from an existing layer in
      gimp_text_layer_from_layer(), steal the old layer's buffer using
      the new gimp_drawable_steal_buffer(), instead of using simple
      pointer assignment, as the latter is generaly unsafe (even though
      it should currently work).
    • Ell's avatar
      Bug 793428 - Errors when loading an XCF with a saved selection mask · 38d4aa81
      Ell authored
      Since commit d0ae244f, which
      connects GimpChannel instances to their buffer's "changed" signal,
      the XCF loading code that steals a channel's buffer when converting
      it to a selection mask (which happens when loading an XCF with a
      saved selection mask) is unsafe, since fails to perform the
      necessary cleanup and setup of the buffer in the old and new
      channel objects, respectively.
      Perform the buffer transfer using the new
      gimp_drawable_steal_buffer(), which does the same thing in a safe
    • Ell's avatar
      app: add gimp_drawable_steal_buffer() · b50be495
      Ell authored
      ... which transfers a buffer from one drawable to another in a safe
      manner, leaving the source drawable empty.
      There are already two ad-hoc instances where we steal a drawable's
      buffer through simple pointer assignment, however, this avoids
      performing potentially necessary cleanup and setup.  In particular,
      since commit d0ae244f this causes
      actual errors.  The next two commits replace those instances with
      calls to gimp_drawable_steal_buffer().
    • Ell's avatar
      app: allow passing a NULL buffer to gimp_drawable_set_buffer[_full]() · 24fcabc1
      Ell authored
      ... which clears the drawable's buffer, performing any necessary
      cleanup, without setting a new buffer.  While the drawable has no
      buffer, it can only be used in a very limited way, in particular,
      it may be destroyed, and it may be assigned a new buffer.
      This is used by the next commit to implement
      gimp_drawable_steal_buffer(), which transfers a buffer from one
      drawable to another in a safe manner, leaving the source drawable
    • Piotr Drąg's avatar
      Update Polish translation · 13f638fb
      Piotr Drąg authored
    • Jehan's avatar
      app: when WARNING or CRITICAL debugging are ignored, go to terminal. · 37f99069
      Jehan authored
      Current code was redirecting WARNING and CRITICAL errors to normal
      messaging when the debugging was deactivated (in Preferences). But if
      you deactivate these on purpose, then it means you don't want to get
      annoyed by small pop-ups either.
      This commit makes them directly displayed in terminal, as they used to
      before, when debugging is deactivated.
    • Marco Ciampa's avatar
      Updated Italian translation · a1b1f53b
      Marco Ciampa authored
    • Jehan's avatar
      NEWS: keep up-to-date. · 5b3c1822
      Jehan authored
  4. 12 Feb, 2018 23 commits
    • Jehan's avatar
      data: improve the tip about the save and export format. · 127b8470
      Jehan authored
      Current phrasing seemed to imply that you could chose another format
      than XCF to *save* your work-in-progress image. Reword a bit to make
      obvious that "saving" is always done with XCF. Other formats are for
    • Jehan's avatar
      app: auto-backup of current work-in-progress images during a crash. · d916fedf
      Jehan authored
      As previously explained, this was the next and logical step after
      debugging. At the very end, just before exiting the process, let's
      attempt to save all unsaved (i.e. "dirty") images. Of course we try to
      do so as backup files in the config directory (once again, this would
      be better under $XDG_CACHE_HOME/GIMP/ though) because we must not touch
      the originals.
      Currently we only have some automatic saving, but we don't warn yet that
      backups were made. Also we don't keep track of the original paths for
      later recovery hints. Proposed recovery would be worth being done at
      next start of GIMP when we detect files in the backup directory (with a
      typical "What should we do with these?" dialog).
      Also it is to be noted that it is not a 100%-sure system. While testing
      various test cases, I had many cases where the images were successfully
      saved, but others when the backup failed (in particular when playing
      with double freeing). I'm not sure if this is because of some memory
      allocation during XCF saving or some other issue which could be improved
      later (hopefully).
    • Ell's avatar
      Bug 793392 - Issue when painting with some layer modes ... · 1be00225
      Ell authored
      ... on perceptual gamma image
      When constructing the paint core's paint buffer, in GimpBrushCore
      and GimpInk, use the drawable's format as the preferred format in
      the call to gimp_layer_mode_get_format(), instead of NULL.
      Subsequently, use the paint buffer's format, instead of the source
      buffer's format, as the preferred iterator format in
      do_layer_blend(), since the iterator format must match the paint
      buffer format.
    • Ell's avatar
      app: improve gimp_layer_mode_get_format() · 8d3b2872
      Ell authored
      When the layer mode is composite-space agnostic, return a fast
      format based on the preferred format's model, not the exact format.
    • Jehan's avatar
      app: add a g_return_val_if_fail() to avoid a crash. · ec14e100
      Jehan authored
      It seems gegl_buffer_sample() crashes with the first parameter being
      NULL so let's just test its value first. This will output a huge
      quantity of CRITICALs in this edge case but that's much better than a
      crash. :-)
      See also bug 793371 where this bug is being processed.
    • Jehan's avatar
      app: switch to #ifdef GEGL_BUG_645810_SOLVED code. · 2956cde6
      Jehan authored
      When checking the Cage Transform operation code, I saw some ifdef meant
      to be switched to when bug 645810 is fixed. It also says in a comment:
      > /* When Gegl bug #645810 will be solved,
      >    this should be a good optimisation */
      Checking said bug, it appears it has been fixed since 2012!
      I also fixed a bit the parameters in gegl_buffer_sample() call since it
      seems the function signature has changed quite a bit.
    • Jehan's avatar
      build: fix header search paths for windres calls (Win32 build). · 5b58cc4b
      Jehan authored
      The Win32 build was not taking the new path of git-version.h into
      account and was outputting these errors:
      > ../build/windows/gimp.rc:2:10: fatal error: git-version.h: No such file or directory
      >  #include "git-version.h"
      >           ^~~~~~~~~~~~~~~
    • Jehan's avatar
      Bug 793393 - gimputils.c compilation error under Win32. · 1282a95e
      Jehan authored
      The header sys/wait.h is not for Win32.
    • Jehan's avatar
    • Jehan's avatar
      app: add GIMP_MESSAGE_BUG_WARNING + GIMP_MESSAGE_BUG_CRITICAL severity. · 77ed4761
      Jehan authored
      Since a few commits, I don't generate the traces anymore in errors.c but
      delay this to gui-message.c and rely on the message severity to decide
      whether or not generating traces.
      Unfortunately none of the current severities are properly describing
      this new type of messages. Even GIMP_MESSAGE_ERROR is used everywhere in
      our code NOT for actual programming bug, but often for data errors
      (which are not bugs but proper messages and should obviously not prompt
      a debug trace).
    • Jehan's avatar
      devel-docs: update the debugging-tips file. · 3dff485d
      Jehan authored
    • Jehan's avatar
      NEWS: keep up-to-date. · 67d0848b
      Jehan authored
    • Michael Natterer's avatar
      Bug 783755 - Smudge should blend the smudged colors using linear RGB · 6f324b86
      Michael Natterer authored
      This reverts commit 94c6bb46, because
      unlike what the bug title suggests, Smudge apparently *should* use
      perceptual RGB, so now everything works as before.
    • Michael Natterer's avatar
      app: don't choke when being asked for GIMP_UNIT_PERCENT's factor or digits · 3bea6dce
      Michael Natterer authored
      Instead, return bogus default values just like libgimp/gimpunitcache.c
    • Michael Natterer's avatar
      Bug 793276 - Make jitter scale run to 5 instead of 50 · a86eee6a
      Michael Natterer authored
      Limit the scale's range to [0..5] while keeping it possible to set
      jutter as large as the old maximum of 50.
    • Michael Natterer's avatar
      Bug 400448 - ruler subdivision is wrong for inches · fd37737f
      Michael Natterer authored
      This commit changes nothing, but contains disabled proof-of-concept
      code to use different ruler subdivisions depending on the ruler's
    • Ell's avatar
      app: don't disable undo for unattached items in gimp_item_{start,end}_move() · ac339247
      Ell authored
      Setting push_undo to FALSE in these functions is premature -- let
      this stuff be handled at the actual point where the undo is
      pushed, which might correspond to a different item than the one for
      which gimp_item_{start,end}_move() was called.
      In particular, when removing a layer from the image,
      gimp_item_end_move() is called (with push_undo == TRUE) on the
      layer after it's been removed, but we still need the appropriate
      undo enrties to be pushed for the affected group layers.
    • Ell's avatar
      Bug 793373 - Crash when ctrl-alt-clicking, dragging then releasing... · 68e37f28
      Ell authored
      ... a selection.
      The crash was the result of an unmatched gimp_item_end_move() call,
      which is an error.  Add the matching gimp_item_start_move() call
      when starting to drag a selection in GimpEditSelectionTool.  Revert
      last commit, so that unmatched gimp_layer_end_move() calls are not
      silently ignored, and add a check instead.
    • Jehan's avatar
      Bug 793373 - Crash when ctrl-alt-clicking, dragging then releasing... · d9987ea7
      Jehan authored
      ... a selection.
      The regression appeared with commit 10c125c6.
      gimp_layer_end_move() may sometimes run even while a symmetric
      gimp_layer_start_move() had not run. For instance this happens when
      releasing the mouse button after dragging a ctrl-alt-click created
      floating layer.
      Therefore let's check that layer->move_stack is not NULL before
      dereferencing it.
    • Jehan's avatar
      app: make backtrace processed in the thread where error happens. · b0cd4412
      Jehan authored
      Slight back step from commit 34fe992f. I don't keep track anymore of
      the number of errors inside GimpCriticalDialog. The problem is that GTK+
      calls must happen in the main thread, and errors in another thread will
      be delayed into the main thread through gdk_threads_add_idle_full().
      This makes any backtrace generated as a consequence of a threaded error
      useless (in particular any error happening in GEGL since we always
      process these as multi-threaded, whether they are or not).
      Instead I now keep track of the number of errors in gui-message.c, which
      still allows to reset the counters when the unique debug dialog is
      closed. Therefore I can now generate backtraces conditionally to the
      error counters inside the problematic thread (and right when the error
      happened), without any GTK+ call.
      This finally makes GEGL backtraces useful in the debug dialog! :-)
    • Jehan's avatar
      app: handle GEGL WARNING and CRITICAL with the new debugging GUI. · 5d200c2c
      Jehan authored
      It is not always very useful since GEGL makes heavy use of threads, and
      therefore a backtrace of the main thread for an error on another thread
      is mostly useless. But that's a start. I am still improving.
      I was holding on non-GIMP messages until now because we don't have as
      much control on them, and for some errors, they may be huge. For
      instance, the bug told by Massimo in bug 792787, comment 22, generates
      hundreds of thousands (and even millions for big enough polygons) of
      errors. But I can now allow these to pass since previous commit when I
      now only display a few errors, and then redirect remaining errors to
      Also get rid of gimp_third_party_message_log_func() and instead make
      gimp_message_log_func() handle correcly non-GIMP messages by keeping
      their domain.
    • Jehan's avatar
      app: keep track of number of errors and traces in GimpCriticalDialog. · 34fe992f
      Jehan authored
      We don't want an infinite number of traces because it takes some time to
      get. Until now I was keeping track of traces in app/errors.c, but that
      was very sucky because then I was limiting traces per session. Instead
      save them as a variable of a GimpCriticalDialog instance. Therefore only
      generate the traces for WARNING/CRITICAL at the last second, when
      calling the dialog.
      When too many traces are displayed, just fallback to just add error
      messages only. But then even errors without traces can be time-consuming
      (if you have dozens of thousands of errors in a few seconds, as I had
      the other day, updating the dialog for all of them would just freeze the
      whole application for a long time).
      So also keep track of errors as well and as last fallback, just send the
      remaining errors to the stderr.
    • Jehan's avatar
      libgimpbase: allow NULL prog_name in gimp_print_stack_trace(). · 4e293a86
      Jehan authored
      The only debugger command which uses this value currently is gdb. And
      even there, it doesn't look mandatory. The alternative call using "-p"
      option does not require the program name. The manual doesn't say if
      calling with the program name has any advantage (but I don't see why it
      would, the PID is enough to find a process). Just in case, I leave the
      prog_name parameter (because it's easier to make a parameter useless
      than changing a libgimp* API) but simply allows setting it to NULL.
  5. 11 Feb, 2018 3 commits
    • Jehan's avatar
      libgimpbase: use backtrace_symbols_fd() rather than... · 04053324
      Jehan authored
      ... backtrace_symbols() when possible.
      When we allocate a new string, anyway we have memory allocation. But
      when we just print to a file descriptor, this version of the API is
      guaranteed without any memory allocation and therefore should always
      work. This is important since allocations may fail in particular after
      memory errors.
    • Michael Natterer's avatar
      app: replace all g_assert() by the newly added gimp_assert() · 539927eb
      Michael Natterer authored
      which is just a #define to g_assert for now, but can now easily be
      turned into something that does some nicer debugging using our new
      stack trace infrastructure. This commit also reverts all constructed()
      functions to use assert again.
    • Piotr Drąg's avatar
      Update Polish translation · 6db5ba61
      Piotr Drąg authored