… whether the program is really ready to accept various commands.
In particular, on macOS, one could drop an image to the app icon in the
dock while starting up (visible splash). Then if the profile convert
dialog appears *behind* the splash, it would block loading until an
action is taken (unfortunately as it's hidden, people may miss it and
would think GIMP froze), as reported by cyril and reproduced by lukaso.
I can't test myself, but I'm hoping this will fix the issue (similar to
commit a86ed68870 where we had a similar issue with dbus file opening
on Linux).
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.
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.
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.
In gimp_init(), call gimp_enums_init(). We need to make all enum types
known to the type system by name because the PDB is now based on enum
type names.
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()`.
Add "gboolean push_undo" parameters to gimp_image_parasite_attach()
and _detach() and use the API also from undo, instead of implementing
attaching/removing manually and forgetting about the signals.
Fixes updating of the image properties color profile page.
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
implemented.
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.
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.
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.
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).
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.
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
terminal).
... it doesn't exist.
The tmp/ dir in the config folder should already be created by GIMP, but
just in case it is not there, try and create it, since all code calling
these assumes that it exists.
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.
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.
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).
More than 2000 lines of code less in app/, instead of
if (instance->member)
{
g_object_unref/g_free/g_whatever (instance->member);
instance->member = NULL;
}
we now simply use
g_clear_object/pointer (&instance->member);
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/.
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,
and initialize units in gimp_init(). This was completely
over-engineered but in the end boils down to a bad hack that needs a
static "the_unit_gimp" pointer anyway, so let's at least have the hacks
in one file.
... to avoid long pause on start
On non-Linux operating systems the fontconfig cache is often not
initialized by default. The first time GIMP was launched, this led
to a non-responding application, confusing many users.
The initialization of fontconfig has now been moved to a separate
thread. The main thread will wait for this fontconfig thread to
complete, regularly pulsing the UI.
This patch was partly based on an earlier patch by Tor Lillqvist.
We needed to get rid of these images at a later point. This fixes (at
least) a crash seen on Mac OS X, where the images were being unreffed
before the last GimpActions (with a reference to the image) were
unreffed.
This preparation commit only moves code around and renames it, the
history is still a list of plug-ins only:
- move app/core/gimp-filter-history.c
to app/plug-in/gimppluginmanager-history.c and clean it up
- move the actions that create the submenus under "Filters"
from the "plug-in" to the "filters" action group
- move the code that creates and updates the history actions
to the "filters" action group
- add menu setup code for the "filters" menu
- move the "history-changed" signal from GimpPlugInManager to Gimp
- GimpContext API and property
- a GimpDataFactory
- List and grid views with GimpDataFactoryView
- actions and a context menu
None of this is connected to the actual tool yet, or depends on
libmypaint in any way.
