1. 23 Mar, 2018 2 commits
  2. 07 Mar, 2018 10 commits
  3. 04 Mar, 2018 1 commit
  4. 27 Feb, 2018 1 commit
  5. 26 Feb, 2018 1 commit
    • Jehan's avatar
      Bug 793815 - segmentation fault on a handler using finalized user data. · b671a43a
      Jehan authored
      The bug is very hard to reproduce, probably because it requires specific
      timing conditions but this looks like this commit would prevent it.
      Apparently the signal handler gimp_container_view_name_changed() may
      have been run while the container view (set as user data) was most
      likely already finalized, hence leaving an invalid dangling pointer.
      Let's just make sure we disconnect this handler (and another) when we
      finalize the container view and its private data.
  6. 21 Feb, 2018 2 commits
    • Jehan's avatar
      app: replace GimpHistogramEditor's "valid" by "recompute" flag. · 1a8edbed
      Jehan authored
      Having to sync the "valid" flag with the presence of a histogram is
      error-prone (cf. previous commit).
      Instead gimp_histogram_editor_validate() return value will just depend
      on the presence of the histogram. And "valid" becomes "recompute", i.e.
      a flag to request for "recomputation" of the histogram.
    • Jehan's avatar
      Bug 793669 - histogram-related bug report. · 35352519
      Jehan authored
      When the histogram is freed, we need to set valid to FALSE, in order to
      force recreation as soon as needed. Otherwise we may hit some race
      condition of trying to work with a NULL histogram. For instance this
      happened when starting painting fast enough after switching the active
  7. 17 Feb, 2018 5 commits
    • Ell's avatar
      app: more action history sorting logic improvements/fixes · bdab2829
      Ell authored
      Simplify the action history sorting logic introduced in the
      previous commit, and fix a few issues in its implementation.
    • Ell's avatar
      app: improve action history sorting · 2e544833
      Ell authored
      The current sorting logic of actions in the history is essentially
      linear, so that when an action is activated it moves up one place
      in the history.  This has the undesirable effect that actions take
      very long to climb up the history list, as well as that actions at
      the top of the list can change their relative order too frequently.
      Improve the sorting logic, such that items climb up the list
      faster, while top items retain their relative position longer.  See
      the comment at the top of the diff for the actual logic.
    • Ell's avatar
      app: exclude undo/redo actions from history · 9653cdfc
      Ell authored
      The undo/redo actions' label changes based on context, and may
      interfere with the labels of more relevant, but less frequent,
      For example, after applying filter Foo, the label of edit-undo
      becomes "Undo Foo", so searching for "Foo" results in both
      edit-undo, and the action referring to the filter, with edit-undo
      most likely appearing at the top of the list due to its frequency.
      Excluding the undo/redo actions from the history is a simple, if
      suboptimal, way to fix this.
    • Ell's avatar
      app: add gimp_action_history_is_blacklisted_action() · 2816695e
      Ell authored
      ... and rename gimp_action_history_excluded_action() to
      is_blacklisted_action() determines whether an action should be
      excluded from *both* the history and the search results, while
      is_excluded_action() determines if an action should be excluded
      only from the history.  This eliminates some redundancy across
      gimpaction-history and action-search-dialog.
    • Ell's avatar
  8. 12 Feb, 2018 3 commits
    • 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
      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: 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.
  9. 11 Feb, 2018 3 commits
  10. 09 Feb, 2018 1 commit
  11. 04 Feb, 2018 3 commits
  12. 03 Feb, 2018 1 commit
    • Jehan's avatar
      app: update a GimpMessageBox repeated in a idle function. · 110779eb
      Jehan authored
      I was directed by Massimo to some bug which was repeatedly generating
      dozens of thousands of GEGL WARNINGs and that was completely taking over
      the GUI if redirected to GimpErrorDialog. Currently GEGL warnings are
      not redirected there, but the problem is still there, and we don't want
      GIMP warnings to freeze the whole GUI either.
      So only increment the repeat variable upon gimp_message_box_repeat() and
      delay actual GUI update to a later low-priority idle function.
  13. 31 Jan, 2018 1 commit
  14. 30 Jan, 2018 1 commit
  15. 29 Jan, 2018 2 commits
    • Jehan's avatar
      app: make the buttons translatable again. · 42e9ddd4
      Jehan authored
      I actually think the buttons were translatable, but the strings were
      simply not auto-extracted with previous code (which is nearly the same
      in the end). Should be better now.
    • Jehan's avatar
      app, tools: rename app/version.[ch] to app/gimp-version.[ch]. · 1b4efd2d
      Jehan authored
      Since commit 9fdf3555, I removed the GIMP_APP_GLUE_COMPILATION check
      because we need to have the whole versioning info from the new debug
      widget. It just makes sense to go further and just make this a proper
      internal API to get version information.
  16. 28 Jan, 2018 3 commits
    • 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
    • Jehan's avatar
    • 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.