The scratch allocator has been moved to GEGL (commit
gegl@b99032d799dda3436ffa8c1cc28f8b0d34fb965d). Remove gimp-
scratch, and replace all its uses with gegl-scratch.
Move swap/cache and temporary files out the GIMP user config dir:
libgimpbase: add gimp_cache_directory() and gimp_temp_directory()
which return the new default values inside XDG_CACHE_HOME and the
system temp directory. Like all directories from gimpenv.[ch] the
values can be overridden by environment variables. Improve API docs
for all functions returning directories.
Add new config file substitutions ${gimp_cache_dir} and
${gimp_temp_dir}.
Document all the new stuff in the gimp and gimprc manpages.
app: default "swap-path" and "temp-path" to the new config file
substitutions. On startup and config changes, make sure that the swap
and temp directories actually exist.
In the preferences dialog, add reset buttons to all file path pages.
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
A single icon theme can contain both regular and symbolic icons. Let's
give possibility to switch from one style to the other within GIMP
Preferences.
This won't work very well in all cases yet, especially if an icon theme
only has symbolic icons (and no regular ones) because of inconsistencies
in glib which are being fixed (patches which I submitted and which were
merged in glib on 2018-08-17).
So this will work as expected when we will bump our glib requirement to
whatever is the next release.
Preview generation for layer groups is more expensive than for
other types of drawables, mostly since we can't currently generate
layer-group previews asynchronously. Add a preferences option for
enabling layer-group previews separately from the rest of the
layer/channel previews; both of these options are enabled by
default. This can be desirable regardless of performance
considerations, since it makes layer groups easily distinguishable
from ordinary layers.
... --enable-relocatable-bundle option.
This will allow to use this option for more than MyPaint brushes. For
macOS and Windows, we default to "yes" and "no" for other OS, though it
is always possible to set an explicit value.
...upon exporting an image
Step 1: make it configurable just like "Export EXIF" etc.
app, libgimp: add "export-color-profile" config option
Add it to the preferences dialog, and pass it on to plug-ins in the
GPConfig message. Add gimp_export_color_profile() to libgimp.
Nothing uses this yet.
Also remove all traces of it from the plug-in protocol and raise the
protocol version to 0x0100 (we now allow features and therefore
version bumps in stable, and the master protocol version should always
be higher). Fix the code that aborts plug-in startup on protocol
version mismatch, we can't use gimp_message() because we have no
protocol.
With GTK+3, high or low density is taken care by the screen scale
factor. Having a separate preferences for this is redundant, and likely
even wrong.
It may be interesting though to have a new preference later, which would
allow smaller scale icon sizing since some people like their icon
slightly smaller or bigger, and also when you are using screens whose
density is at a limit scale factor. Right now, this can be done through
themes, but a GUI settings may be interesting. If I add such feature,
let's just do it from scratch later.
GTK+ has the concept of theme variants, and in particular if we prefer
the dark variant of a theme. This can be chosen globally but also
per-application. Make this choice customizable in the Theme tab of
Preferences.
By default, the dark variant will be prefered.
Add GimpGuiConfig::filter-tool-use-last-settings wchich defaults to FALSE.
Honor the new option in gimp_gegl_procedure_execute_async() and add
it to prefs -> dialog defaults.
because a simple platform dependency in gimpcoreconfig.c doesn't do
the trick (there can be both manual builds and bundled builds on
windows and macos). Use an AC_DEFINE() instead.
Also, make sure the system gimprc and its manpage are generated with
the correct values.
Some gimprc properties' default values depend on the machine where
"make dist" in run. We had an ugly hack in place to force
(num-processors 1) in the installed system gimprc and its manpage, but
were still leaking "tile-cache-size" and "mypaint-brush-path".
The files are generated by the hidden options --dump-gimprc-system
and --dump-gimprc-manpage which exist only for this purpose.
In gimpconfig-dump.c, special case the three properties in
dump_gimprc_system() and dump_gimprc_manpage() to output constant
default values for "num-processors" and "tile-cache-size" and
output @mypaint_brushes_dir@ in "mypaint-brush-path" which can
be replaced at configure time.
Also introduce etc/gimprc.in so @mypaint_brushes_dir@ can actually be
substituted for the installed system gimprc.
Otherwise the brushes won't be found when bundling on macOS or with the
Windows installer. Build-time path from configuration is still used on
other platforms.
After many discussions, it has been decided to export the metadata by
default since it seems to be what many people would expect and they
would consider they "lost" metadata (especially if they overwrite their
original). I don't entirely agree since privacy (particularly if you are
not aware of metadata and information they may contain) is also an issue
but not many seem to agree with me.
So here it is! All metadata now exported as a default!
The debug dialog is awesome and extremely helpful, but I realize it may
be a better default experience on *stable* to raise it only in case of
crashes. CRITICAL are bad and should be fixed, but sometimes their
consequence is actually not visible except for this dialog, and people
on stable builds may prefer not to see this dialog. Also we will likely
get a lot of duplicates for the same bugs once everybody has this by
default, which will be very annoying to attend to, unless we had
automation (which we don't right now).
The option is still available in preferences anyway so people really
interested in helping can activate the option for CRITICAL and even
WARNING anyway, even on stable releases.
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.
Replacing the boolean property "generate-backtrace" by an enum
"debug-policy". This property allows one to choose whether to debug
WARNING, CRITICAL and FATAL (crashes), or CRITICAL and FATAL only, or
only FATAL, or finally nothing.
By default, a stable release will debug CRITICAL and crashes, and
unstable builds will start debugging at WARNINGs.
The reason for the settings is that if you stumble upon a reccurring bug
in your workflow (and this bug is not major enough for data corruption,
and "you can live with it"), you still have to wait for a new release.
At some point, you may want to disable getting a debug dialog, at least
temporarily. Oppositely, even when using a stable build, you may want to
obtain debug info for lesser issues, even WARNINGs, if you wish to help
the GIMP project.
It can be argued though whether the value GIMP_DEBUG_POLICY_NEVER is
really useful. There is nothing to gain from refusing debugging info
when the software crashed anyway. But I could still imagine that someone
is not interested in helping at all. It's sad but not like we are going
to force people to report. Let's just allow disabling the whole
debugging system.
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.
... be used effectively.
We have had display pixel density detection for quite some time, but I
guess the step I set to switch to the "Huge" icon size (48px for the
toolbox icons) was too high at 300 PPI. Someone with a screen of about
280PPI reported the icons to be far too small on GIMP 2.9.8.
It seems that 240PPI is already even considered as XDPI already. Let's
just set our new "Huge" step at the 250PPI intermediate.
In any case, it seems GIMP 2.10 will have problems with even denser
displays, but the way GTK+2 handles icon sizes with a GTK_ICON_SIZE_*
enum is quite limited. That is quite a problem considering screens
getting denser in pixels nowadays. Hopefully GTK+ 3 will improve the
situation.
Add "color-profile-path" to GimpDialogConfig to remember the last-used
path in any profile chooser dialog.
Whenever a GimpColorProfileChooserDialog is created, call a new
gimpwidgets-utils helper function that connects to the dialog's "show"
and "response" signals and makes sure "color-profile-path" is set on
the dialog if it doesn't have a current folder already, and sets the
property back to the config object when a profile was actually chosen
from disk.
This ensures that MyPaint default brushes are installed, otherwise this
makes the MyPaint brush tool quite useless and confusing unless MyPaint
is installed (which was making MyPaint a de-facto dependency of GIMP
until this commit!). Also we won't have to guess anymore the right path
for these brushs. The path will be known at compile time.
sabri ünal