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.
(cherry picked from commit a4e77e57f6)
This is mostly core code which we want to keep in sync with master as
long as possible, so I picked this one even though not strictly
neccessary.
(cherry picked from commit 1b7d63cce9)
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.
(cherry picked from commit 2484dec7d5)
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.
They were also serialized correctly before, but only because many
GimpData objects were (bogusly) always dirty after loading, which
caused them to always be written do disk on exit. This commit fixes
this problem and updates by-name references explicitly as things are
renamed, instead of relying on bugs.
Add gimp_data_factory_data_clean() which clears the dirty flags from
all a factory's objects. Call the new function on all factories at the
end of gimp_restore(), when all data has been loaded. This might be
total overkill, but ensures that everything is clean in the beginning.
Add new signal GimpContext::prop_name_changed() which is emitted when
any of the context's object properties (brush, gradient etc) is
renamed.
In GimpToolPreset, connect to the new signal and dirty the preset if a
relevant object propery was renamed, making sure the preset is saved
to disk later. Also optmize updates quite a bit by ignoring
notifications on tool option properties that are irrelevant to the
preset.
This might or might not address the issues discussed in bug #739487.
Add a generated palette which contains the color history. For now it's
only updated when the color dialog's color history gets updated, but
should be updated whenever a color is chosen in any way.
Don't try to load palettes and gradients with unknown extension. We
introduced extensions for these files a *lot* of years ago, so we're
dropping this legacy feature now, everybody can just rename their old
files to have the right extensions (the file formats have not
changed).
The page is shown by default in unstable but needs --show-playground
in stable versions. There is nothing yet on that page. Also, the icon
needs improvement...
