1. 17 Jul, 2020 1 commit
    • Jehan's avatar
      app: show playground if any of the experimental feature is enabled. · d3ef6cfb
      Jehan authored
      Basically if you enabled OpenCL or any of the experimental tools, it
      will show the Playground in Preferences. Otherwise, say you enabled some
      experimental feature months ago (e.g. with the CLI option) and you now
      experience crashes or whatnot. And you forgot how to change it, and only
      remembered that there was something in Preferences. It would make you
      crazy to not find the tab again to disable the option.
      This is even more important as OpenCL is moving from a normal option to
      a playground option. So you might not even have ever seen the Playground
      tab in Preferences and would not know how to disable OpenCL after you
      enabled it originally in "System Resources" tab.
      So now Playground is visible with any of these 3 conditions:
      * If you use an unstable version.
      * If you run GIMP with --show-playground option.
      * If you previously enabled one of the playground options.
  2. 01 Feb, 2020 1 commit
    • Ell's avatar
      app: add a "Use tool groups" option to the toolbox preferences · 3cda9721
      Ell authored
      Add a new Gimp::tool_item_ui_list, which is a GimpTreeProxy over
      Gimp::tool_item_list.  This allows us to use either a hierarchical
      or a flat tool list in the UI, by setting the "flat" property of
      the new list.
      Use Gimp::tool_item_ui_list in GimpToolPalette, so that the toolbox
      layout is affected by this choice.
      Add a "Use tool groups" toggle to the toolbox preferences, and bind
      it to the "flat" property of Gimp::tool_item_ui_list.
  3. 30 Jan, 2020 1 commit
    • Ell's avatar
      app: add support for tool groups in toolrc · cd2adfbe
      Ell authored
      Add a new Gimp::tool_item_list list, in addition to
      Gimp::tool_info_list.  The latter may contain arbitrary tool items,
      including tool groups, and is intended for use in the UI (namely,
      the toolbox and the preferences tool editor).
      In gimp-tools, use Gimp::tool_item_list for representing the UI
      tool order (while still using Gimp::tool_info_list as a flat list
      of all GimpToolInfo objects), and add support for saving and
      loading tool groups to/from toolrc.
      Introduce file-version tracking in toolrc, and drop its contents on
      version mismatch, or when new tools are introduced.  This is
      slightly disruptive, but merging new changes with existing toolrc
      files is non-trivial, and it doesn't happen very often.
      Add support for a sysconf toolrc file, which is used if there's no
      user toolrc file (i.e., on first use).  If neither file is found,
      the hard-coded flat tool order is used.  This commit doesn't
      provide a default toolrc file, but the next commits will.
      Make the gimp-tools serialization and deserialization functions
      public, for use in GimpToolEditor in the next commits.
  4. 23 Aug, 2019 1 commit
  5. 12 Aug, 2019 1 commit
  6. 07 Aug, 2019 1 commit
    • Niels De Graef's avatar
      app/core: Use NULL for "simple" signals · 39e4aa3c
      Niels De Graef authored
      Apart from being less code, this actually gives us a nice performance
      improvement. Up until a few years ago, if you pass `NULL` as the
      marshaller for a signal, GLib would fall back to
      `g_cclosure_marshal_generic` which uses libffi to pack/unpack its
      arguments. One could avoid this by specifying a more specific
      marshaller which would then be used to immediately pack and unpack into
      GValues with the correct type.
      Lately however, as a way of optimizing signal emission (which can be
      quite expensive), GLib added a possibility to set a va_marshaller, which
      skips the unnecessary GValue packing and unpacking and just uses a
      valist variant.
      Since the performance difference is big enough, if the marshaller
      argument is NULL, `g_signal_new()` will now check for the simple
      marshallers (return type NONE and a single argument) and set both the
      generic and the valist marshaller. In other words, less code for us with
      bigger optimizations.
      In case you also want va_marshallers for more complex signals, you can
      use `g_signal_set_va_marshaller()`.
  7. 03 Aug, 2019 1 commit
  8. 30 May, 2019 1 commit
  9. 11 Feb, 2019 1 commit
    • Michael Natterer's avatar
      app, plug-ins: start consolidating brush and pattern loading/saving code · a4e77e57
      Michael Natterer authored
      We currently have brush and pattern I/O code in both the core and
      plug-ins. This commit starts removing plug-in code in favor of having
      one copy of the code in the core, much like XCF loading and saving is
      Add app/file-data/ module with file procedure registering code, for
      now just with an implementation of file-gbr-load.
      Remove the file-gbr-load code from the file-gbr plug-in.
  10. 07 Aug, 2018 1 commit
    • Jehan's avatar
      app: extensions can now install splashes. · 7d611e71
      Jehan authored
      Not the most useful type of extensions per-se, but a lot of people seem
      to appreciate creating and installing new splashes. Let's make it easy
      to install as extensions.
      Note that extension splashes are cumulative. So if you enabled several
      splash extensions at once, an image would be chosen in random amongst
      all of them.
  11. 17 Jul, 2018 1 commit
    • Jehan's avatar
      app: serialize and deserialize extensionrc from GimpExtensionManager. · 02aec4c3
      Jehan authored
      We only save the active state of extensions so that we can reload all
      extensions same as they were at previous exit. All other data are saved
      as per-extension metadata and should not be saved in the rc file.
      If an extension is not listed in extensionrc, we run it by default if
      this is a system extension (so that new core extensions by the GIMP team
      are run when installed after an updated), but not when they are
      user-installed extensions.
  12. 11 Jul, 2018 1 commit
  13. 02 Jul, 2018 1 commit
    • Jehan's avatar
      app: add base classes for the extension manager. · b70424b2
      Jehan authored
      Right now it only loads AppStream data, which is completely useless, yet
      is a base of a managed extension system. Having proper metadata is what
      will allow to actually know what is installed.
      This is only the first draft.
      Note that I am not adding the extension path into GimpCoreConfig on
      purpose, since the point is not to have people manage their extension
      directories manually anymore.
      The extensions will be loaded from the build-time system path or the
      config directory, and that's all.
      What will probably be stored in the config though will be the remote
      repositories URLs (allowing third-party extension repositories).
  14. 02 Jun, 2018 1 commit
  15. 01 Jun, 2018 1 commit
  16. 27 May, 2018 1 commit
    • Jehan's avatar
      Issue #1211: Load fonts in background after startup. · 2484dec7
      Jehan authored
      Fonts should not be blocking startup as this provides a very bad
      experience when people have a lot of fonts. This was experienced even
      more on Windows where loading time are often excessively long.
      We were already running font loading in a thread, yet were still
      blocking startup (thread was only so that the loading status GUI could
      get updated as a feedback). Now we will only start loading and proceed
      directly to next steps.
      While fonts are not loaded, the text tool will not be usable, yet all
      other activities can be performed.
  17. 01 May, 2018 1 commit
    • Jehan's avatar
      app: popup error at startup when some fonts fail to load. · e796e3a5
      Jehan authored
      As proposed on IRC. This will allow people to debug their fonts (for
      instance when there are permission issues or whatnot) by knowing the
      list of problematic fonts in an error dialog at startup (and not only on
  18. 22 Apr, 2018 1 commit
  19. 29 Mar, 2018 1 commit
    • Ell's avatar
      app: add --show-debug-menu command-line option · 53c145c0
      Ell authored
      The debug menu is currently not included in stable versions.
      Include the menu unconditionally, but hide it, and its associated
      actions, by default in stable versions.  Allow enabling the menu
      using a new --show-debug-menu command-line option, in the same vein
      as --show-playground.
  20. 12 Feb, 2018 1 commit
    • 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.
  21. 28 Jan, 2018 1 commit
    • 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).
  22. 15 Jul, 2017 1 commit
  23. 03 Jan, 2017 2 commits
  24. 25 Nov, 2016 1 commit
  25. 11 Nov, 2016 3 commits
  26. 10 Nov, 2016 1 commit
  27. 30 Sep, 2016 1 commit
  28. 20 Sep, 2016 1 commit
  29. 19 Sep, 2016 1 commit
  30. 17 Sep, 2016 1 commit
  31. 15 Sep, 2016 2 commits
  32. 13 Sep, 2016 3 commits
    • Michael Natterer's avatar
      Bug 599573 - Remember dialog defaults between Gimp sessions · 20a32d97
      Michael Natterer authored
      Add GimpFillOptions and GimpStrokeOptions to GimpDialogConfig and use
      them in the Fill/Stroke Selection/Path dialogs and for the "with last
      values" commands. Add GUI for them to Preferences -> Dialog Defaults.
      This requires most of the stuff in my last few commits, and some
      more changes:
      GimpFillOptions is a GimpContext which has all sorts of connections to
      everything, including a Gimp pointer. Hack around in GimpDialogConfig
      to add a Gimp property, and add "gimp" parameters to quite some GimpRC
      functions. Treat the Gimp* as a GObject* in all public API because
      core/ stuff is not known in config/.
    • Michael Natterer's avatar
    • Michael Natterer's avatar
      app: create members of the Gimp instance earlier · 314027f0
      Michael Natterer authored
      Move fonts, data factories, document list, paint methods and user
      context creation to gimp_init() or gimp_constructed() so that most
      members are created when gimp_new() is done. This does not load any
      data earlier, it just makes sure that all containers exist when
      gimp_load_config() is called. It's also cleaner and less fragile,
  33. 12 Sep, 2016 2 commits