1. 10 Apr, 2018 1 commit
  2. 04 Apr, 2018 5 commits
    • Jehan's avatar
      libgimp: add an exception handler for Windows. · fa02a2c6
      Jehan authored
      Drmingw already added its own exception handler which generates crash
      traces in a text file, for plug-ins as well. This additional handler is
      run after Drmingw handler and allows us to do things on our own, and in
      particular we could display the content of the debug traces.
      
      Right now it simply prints these to stderr, which actually won't be of
      much use on Win32, first because the console is deactivated on stable
      releases, also because after tests, it doesn't look like even running
      GIMP from cmd outputs to console either.
      
      We currently don't use the same debug dialog as the core on purpose,
      because we don't want everyone to send us traces for every unmaintained
      third party plug-ins out there. But we should definitely allow easier
      trace possibilities at some point, first to improve/debug our own core
      plug-ins, and also to help third party plug-in developers!
      So this commit is not making visible changes yet but is actually a first
      step towards these debugging goals.
      fa02a2c6
    • Jehan's avatar
      libgimp: various warning fixes for Win32. · 76bce77d
      Jehan authored
      76bce77d
    • Jehan's avatar
      libgimp: do not end the fatal and signal handlers with gimp_quit(). · 9c8a8ae5
      Jehan authored
      When ending with gimp_quit(), GIMP was not displaying the "Plug-in
      crashed" error dialog, which is not good, since we lose the crash
      feedback for plug-ins. Just let the plug-in continue its normal run in
      order to get the error dialog.
      Also protect the tracing functions, which are not working on Win32.
      9c8a8ae5
    • Jehan's avatar
      libgimp: add a gimp_fatal_func() allowing stack tracing plug-ins on... · e98b9376
      Jehan authored
      ... various crashes.
      e98b9376
    • Jehan's avatar
      libgimp: properly catch SIGABRT signal. · c4621119
      Jehan authored
      SIGABRT was in the switch list in gimp_plugin_sigfatal_handler(), but it
      had not been properly handled with gimp_signal_private(), making this
      switch case useless. Fix this oversight, and while doing so, move it in
      the "fatal error" list for which we may generate stack traces, similarly
      to core signal handling. Indeed this signal can definitely happen during
      various kinds of common bugs and needs to be debugged.
      c4621119
  3. 06 Mar, 2018 1 commit
    • Ell's avatar
      app, libgimp: don't close parent pipes in libgimp; use gimp_spawn_set_cloexec() · 1b1fba19
      Ell authored
      In gimp_plug_in_open(), use gimp_spawn_set_cloexec() to prevent the
      parent's end of the read/write pipes from being inherited by the
      spawned plug-in, instead of passing the corresponding file
      descriptors to the plug-in as command-line arguments, and having
      gimp_main() close them.
      
      Adding new command-line arguments to plug-ins is problematic, since
      their ability to handle them depends on their protocol version,
      which is only communicated after the plug-in is spawned.
      
      Regardless, this is much simpler.
      1b1fba19
  4. 05 Mar, 2018 1 commit
    • Ell's avatar
      app, libgimp: use gimp_spawn_async() when spawning plug-ins · b9e629ab
      Ell authored
      In gimp_plug_in_open(), use gimp_spawn_async(), added in the
      previous commit, instead of g_spawn_async().  See the previous
      commit for the rationale.
      
      Since gimp_spawn_async() doesn't provide a mechanism to perform any
      cleanup in the child before exec()ing, move the closing of the
      parent's end of the read/write pipes from the app to the plug-in's
      gimp_main(), passing the relevant file descriptors to the plug-in
      through argv.
      b9e629ab
  5. 22 Feb, 2018 1 commit
  6. 09 Feb, 2018 1 commit
  7. 19 Jan, 2018 1 commit
    • Jehan's avatar
      libgimp: add gimp_get_pdb_status() to return the status of last... · 2e18c80c
      Jehan authored
      ... procedure call.
      This is needed for plug-ins which depends on other plug-in's procedures.
      If for instance, the second-level plug-in is interrupted interactively,
      we don't want to process this as an error but as a cancellation.
      Therefore we need to know the returned value of the plug-in. Currently
      only way was to use gimp_get_pdb_error() but that was returning a
      human-readable error, not a computer-processable error.
      2e18c80c
  8. 11 Jan, 2018 1 commit
  9. 16 Aug, 2017 1 commit
    • Jehan's avatar
      libgimp, libgimpbase: allow multi-threaded plugins by locking... · 15f73440
      Jehan authored
      ...protocol calls.
      Some calls are waiting for answers, for instance plugin procedures, and
      tiles which expects data and acknoledgement.
      This would result in error messages such as:
      "expected tile ack and received: 5" (5 is GP_PROC_RUN)
      Typically because a thread would run a procedure while another would
      receive tiles.
      15f73440
  10. 01 Feb, 2017 1 commit
  11. 25 Jun, 2016 1 commit
    • Richard Kreckel's avatar
      Bug 768044 - Fix many typos · dd9b0fc5
      Richard Kreckel authored
      This fixes many typos in comments and one in a user-visible string (msgid
      "center abscisse" changed to "center abscissa" in affected po files. too).
      dd9b0fc5
  12. 02 Jan, 2016 1 commit
  13. 11 Aug, 2015 1 commit
  14. 31 May, 2015 1 commit
  15. 20 May, 2015 1 commit
  16. 13 Apr, 2015 1 commit
    • Mukund Sivaraman's avatar
      windows: Call SetDLLDirectory() in the app · 60197c22
      Mukund Sivaraman authored
      With this patch, there should be no more need to set PATH on Windows
      before running GIMP.
      
      This patch was tested by me and drawoc, but there could be some
      undetected issues lurking. Revert if any problems arise.
      60197c22
  17. 12 Aug, 2014 1 commit
    • Jehan's avatar
      Do not use g_io_channel_unix_new() for the win32 platforms. · b8aabcac
      Jehan authored
      It is advised to use the more accurate g_io_channel_win32_new_fd() or
      g_io_channel_win32_new_socket() because GLib can't differentiate between
      file descriptors and sockets on Windows, which outputs a warning when
      there is ambiguity.
      b8aabcac
  18. 24 May, 2014 1 commit
  19. 03 May, 2014 1 commit
  20. 02 May, 2014 1 commit
  21. 10 Apr, 2014 1 commit
  22. 25 Feb, 2014 2 commits
  23. 25 May, 2013 1 commit
  24. 23 Feb, 2013 2 commits
  25. 12 Nov, 2012 1 commit
  26. 07 Nov, 2012 1 commit
    • Michael Natterer's avatar
      Bug 677776 - filter popup windows get hidden behind main image window · 0b56aa0d
      Michael Natterer authored
      On OSX, call [NSApp activateIgnoringOtherApps] when a plug-in dialog
      is shown, so the plug-in process becomes the active app, and the
      dialog gets focussed.
      
      In order to avoid doing this in GimpDialog (which is also used in
      the core), do it in gimp_ui_init() which all interactive plug-ins
      call, and when gimp_temp_proc_run() is called interactively, to
      catch repeated activation of an already running plug-in.
      
      Also, set GimpDialog's initial position to GTK_WIN_POS_CENTER,
      or they will pop up in the top left corner.
      
      Inspired by patches from Simone Karin Lehmann and Daniel Sabo.
      0b56aa0d
  27. 06 Oct, 2012 1 commit
  28. 02 May, 2012 2 commits
  29. 07 Dec, 2011 1 commit
  30. 25 Nov, 2011 1 commit
  31. 28 Apr, 2011 1 commit
  32. 08 Mar, 2011 1 commit
  33. 19 Oct, 2010 1 commit