1. 28 Jan, 2018 15 commits
    • 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 13 commits
  3. 26 Jan, 2018 1 commit
  4. 25 Jan, 2018 1 commit
  5. 23 Jan, 2018 2 commits
  6. 22 Jan, 2018 7 commits
    • Sebastian Rasmussen's avatar
      Bug 792792 - Typo fix for an error message. · 0c34db8a
      Sebastian Rasmussen authored
    • Jehan's avatar
      app: all remaining g_assert() replaced by critical warning and return... · 4c2df9b3
      Jehan authored
      ... in app/core.
      Continuing on my crusade against asserting and crashing GIMP.
    • Jehan's avatar
      app: run gimp_projectable_get_graph() before gegl_node_get_parent()... · b4c7dd8f
      Jehan authored
      ... on top-level layers.
      There was even a comment for this, but I missed this when I moved some
      code to the top of the function in commit b9577a78. Now moving this
      call up as well. This appeared to be more of a problem when merging
      layers without a GUI (script-fu). I'm guessing the GUI calls this anyway
    • Michael Natterer's avatar
      libgimpwidgets: restore ABI of GimpColorSelectorClass · 13b640f8
      Michael Natterer authored
      Public structs must not change, that's why we have padding at the
      end for extension.
    • Jehan's avatar
      app: we should not have any g_assert*() code if possible. · f87bc3fe
      Jehan authored
      Replace all g_assert_not_reached() in app/core/ by g_return_if_reached()
      or g_return_val_if_reached(). GIMP may handle a lot of creative work,
      sometimes unsaved for hours. We should not just crash on purpose.
      g_assert*() could theoretically be turned off on a glib build, but this
      is nearly never done, and is not a solution either (actually it is
      probably even worse because the broken code would just continue on a
      forbidden path). It is much better to return with a warning on such
      forbidden code paths, allowing someone to report a bug without
      experiencing a crash and data loss.
      For now, I only took care of g_assert_not_reached() inside app/core.
      More g_assert*() code should be replaced.
      Note: assert are acceptable in plug-ins though, but not in the main
      executable, unless absolutely necessary (something happening so bad that
      crash is better than continuing).
    • Jehan's avatar
      libgimpwidgets: use g_return_if_reached() in unreachable code path. · 54a1e8f2
      Jehan authored
      This way, we get proper CRITICAL if ever there is a logic error (or in
      this case, if we add new values to enums and forget to append them to
      switch cases.
      This will make these bugs much easier to debug if (when!) they happen.
    • Jehan's avatar
      libgimpwidgets: oups, fix some stupid miswrite. · 90037116
      Jehan authored
      Unfortunately not very problematic, unless when setting alpha channel.
  7. 21 Jan, 2018 1 commit