This reverts commit 94b028bc39c7250997ee9883793e6649bf2490c7.
Dunno what breaks here, it just crashes, leave the commits there
instead of rebasing them away, as reminder...
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.
This new function is available from the released dev version 3.11.4. But
we don't want to require GTK+ master for the gtk3-port branch, so I
leave the old hack in a GTK_CHECK_VERSION() macro, to be removed later
when we update GTK+ required version.
The upper text will be centered on the top quarter of the bottom quarter
of the splash image, whereas the bottom text will be centered on the
bottom quarter of the bottom quarter of the splash (unless the splash is
too small, in which case the double of the layout pixel extents will be
used). Basically don't use absolute pixel values anymore for
positionning. This should all be done relatively since there are
nowadays all kind of display size (and positionning the text 6 pixels to
the bottom, as it was done, may be ok on low density displays, yet will
look ugly on high density screens).
Also write this down in the splash requirements in the release howto so
that splash designers are aware that the bottom quarter of their image
will have to be adapted for printing text.
Last commit caused -xobjective-c to be passed during linking on
Mac, causing object files to be treated as source files. Add a
-xnone flag to AM_LDFLAGS, canceling the effect of -xobjective-c.
Additinally, add a -xobjective-c++ flag to AM_CXXFLAGS, so that we
can use Objective-C in C++ files on Mac, if we ever need to.
On Mac, pass -xobjective-c to the compiler through AM_CFLAGS, not
AM_CPPFLAGS, so that it's only used for C sources, and not C++
sources. In the latter case, it clashes with the -std=... flag,
spewing an error. Thanks, Partha :)
Need to check if we must override PixbufStyle's draw_layout() after
each theme change, not only at the beginning of themes_init(), so it
works also when the the pixbuf engine was not already loaded at
startup.
Turn the g_warning() into a g_printerr().
Duplicate accelerators should not trigger a WARNING, because they come
from a config file and there is nothing that can be fixed in the code
to prevent that.
Apparently former 2/3 value was too big according to some.
This makes the splash take now at most a quarter of the screen area. I
really don't think that's too much anymore.
Not using %d in the singular form of English does not prevent other
languages to use %d in any form they wish to. This will still work and
will still be replaced by the relevant number of images.
So I revert commit a0724783d8 because it is just prettier (in English)
to write "An image" rather than "1 image", but this does not mean you
have to do the same in other languages! Adding a comment so that
translators know about it.
Also directly modify the msgid in the Polish and Russian translations
which already translated this string, so that the translations does not
end up unnecessarily fuzzy.
Since commit d916fedf92, GIMP has had the hidden feature to salvage
images (if possible) during a crash into a backup folder. This commit
finishes the feature by opening a dialog proposing to try and recover
the salvaged images.
This is not perfect yet since it doesn't "remember" the XCF path (in
case it was a previously saved image). The images open as new unsaved
and dirty images, but directly from the contents at crash time. For now,
it is up to people to figure out what they correspond to, if relevant.
Since a few commits, I don't generate the traces anymore in errors.c but
delay this to gui-message.c and rely on the message severity to decide
whether or not generating traces.
Unfortunately none of the current severities are properly describing
this new type of messages. Even GIMP_MESSAGE_ERROR is used everywhere in
our code NOT for actual programming bug, but often for data errors
(which are not bugs but proper messages and should obviously not prompt
a debug trace).
Slight back step from commit 34fe992f44. I don't keep track anymore of
the number of errors inside GimpCriticalDialog. The problem is that GTK+
calls must happen in the main thread, and errors in another thread will
be delayed into the main thread through gdk_threads_add_idle_full().
This makes any backtrace generated as a consequence of a threaded error
useless (in particular any error happening in GEGL since we always
process these as multi-threaded, whether they are or not).
Instead I now keep track of the number of errors in gui-message.c, which
still allows to reset the counters when the unique debug dialog is
closed. Therefore I can now generate backtraces conditionally to the
error counters inside the problematic thread (and right when the error
happened), without any GTK+ call.
This finally makes GEGL backtraces useful in the debug dialog! :-)
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.
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.
This was a bit harder since even though we handle fatal signals,
allowing us to do any last action before GIMP crashes, it seems more
memory allocation is not allowed at this time. So creating a dialog or
simply getting the return output of gdb into the main process is not
allowed. What I do instead is running a separate program (gimpdebug)
which will take care of creating the new dialog and running a debugger.
I still use GimpCriticalDialog code from this separate binary, while I
continue to use this widget also within GIMP for non-fatal errors. The
reason why we still want to use it within GIMP is that we can bundle
several non-fatal errors and backtrace this way (fatal errors don't
return anyway) and it's easier to do so when created from the main
process.
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).
Whereas we would only scale *down* big pixel images, we should both
scale up or down vector images since such format is made for display at
any size. This way, a vector splash screen is always displayed at ideal
size, whatever your display size.
Current code was using the dimension of the screen as a max size. That
is really too big. 2/3 of the screen size is an acceptable size being
both well visible and not overwhelming.
Also the current code was cropping, not rescaling, the splash image,
which is obviously not an acceptable solution because on a very small
displays, we would end up with ununderstandable piece of a bigger image.
This new code will allow to ship big size default splash image(s), and
display it in an acceptable size on both low and high density displays.
We indeed got a feedback from someone with a 4K display who was saying
the current dev splash screen was tiny on one's display.
Of course, custom splash can still be at any size; but from now on, we
will need for the *default upstream splash image(s)* to be of huge
dimension in order to show up well everywhere (at least Full HD splash,
which is half of a 4K UHD screen).
Animated splash images are still not resized though and will show up at
their default dimension. This means we cannot ship animated splash
screens as a default for the time being (they can still be installed as
custom splash).
Replace gimp_parameter_*() utility functions with equivalent
gimp_properties_*() functions which deal with separate arrays of names
and values, and use g_object_new_with_properties() instead of
g_object_newv().
Current logics of dealing with duplicate accelerators was just to delete
one randomly. This works ok in most case since we can't be in the head
of people and can't know which one they want to keep (yet we can't keep
both because that makes it very complicated to reset the shortcut
appropriately by hand/GUI, without a tedious work of researching which
other action uses the same shortcut. See commit 2a232398c4).
There is still some cases where we can be a bit more clever than random
deletion: when one of the accelerator is mapped to a non-existing
action. In this case, let's delete this accelerator in priority. Not
only the chances of this being the expected result are higher; but even
worse, there is anyway no GUI way to delete the accelerator for the
non-existing action! Thus you could try and reset your existing action's
shortcut as many times as you want in the GUI, it would always end up
deleted at next startup!
Note that if the non-existing action's shortcut has no duplicate, it
won't be deleted. This ensure that you could uninstall a plugin, then
reinstall it later and still have your custom shortcuts saved in the
meantime. A shortcut of a non-existing action will *only* be cleaned out
if it is redundant with the shortcut of an existing action.
Massimo is worried that it could unload the module (maybe in some
specific cases?), which could indeed happen when the g_type_class_ref()
just before was the first call to the class (hence it's the only ref).
So let's just unref() in the exit() function instead.
Not sure if g_type_class_ref() can actually return NULL here, but let's
add a check, just in case.
Also unref() after since we ref-ed it ourselves.
Finally reorganize a bit to keep the private functions together and
named appropriately, clean some tabs and add a comment to remind of
further check/cleanup once we port to GTK+3.
Comment by Jehan after review:
"Quick and dirty hack" but a working one. Since the bug will likely
disappear with the GTK+3 port (to be verified) which uses another theme
system, let's just do it this way.
Currently, the error console is highlighted (shown/blinked) only
upon errors; however, warnings, which are not shown on the
statusbar while the error console is open, often also contain
important information.
Allow the user to configure which message types (errors, warnings,
and regular messages) highlight the error console, using a new
"highlight" submenu in the error-console menu. Add corresponding
config options, saved in sessionrc. By default, highlight the
error console unpon both errors and warnings.
Michael Natterer