In some cases, error dialogs may end up below other windows and stay
unnoticed because of how dialogs are raised and hidden on various
platforms. This is not very constructive. It's much better to make sure
one sees an error when it happens (in some cases, it may mean possible
data loss, so it should be at least acknowledged; also seeing it later
may mean you can't know anymore which action triggered this error,
making the whole process kind of meaningless and hard to debug).
So anyway, let's make error messages prominent by having them always
above.
- Set the software as `initialized` later, and in particular after all
recovered images (from crash) then all command line images were
opened. The reason is that the DBus calls have necessarily been made
after GIMP was started (typically could be images double-clicked
through GUI). We don't want them to appear before the images given in
command line (or worse, some before and some after).
- Process DBus service's data queue as a FIFO. The image requested first
will be loaded first.
- When a DBus call happens while GIMP is not initialized or restored,
switch to a timeout handler. The problem with idle handlers is that
they would be attempted too often (probably even more during startup
when no user event happens). This is good for actions we want to
happen reasonably quickly (like would be normally DBus calls), but not
when we are unsure of program availability schedule (i.e. at startup).
Here not only the handler would run a lot uselessly but it would
likely even slow the startup down by doing so. So while GIMP is not
initialized, switch to half-a-second timeout handler, then only switch
back to idle handler when we are properly initialized and GIMP is
ready to answer calls in a timely manner.
… DBus calls.
In particular, Aryeom would start GIMP and directly double click some
image to be loaded in GIMP in the very short while when splash is
visible. Previous code would wait for the `restored` flag to be TRUE.
This was nearly it as we can actually start loading images as soon as
the 'restore' signal has passed. Yet the flag is set in the main
handler, but we actually also need the <Image> UI manager to exist,
which is created in gui_restore_after_callback() (so also a 'restore'
handler, yet after the main signal handler, i.e. after `restored` is set
to TRUE). Without this, gui_display_create() would fail with a CRITICAL,
hence file_open_with_proc_and_display() as well.
I could have tried to set the `restored` flag later, maybe with some
clever signal handling trick (and handle both the GUI and non-GUI cases,
i.e. I cannot set the flag inside gui_restore_after_callback() as it
would break the non-GUI cases). Instead I go for a simpler logics with a
new `initialized` flag which is only meant to be set once, once
everything has been loaded, i.e. once you can consider GIMP to be fully
running hence ready to process any common runtime command.
This is not a fix, only an extra-ugly workaround so that at the very
least we don't end up with a splash screen taking the whole display on
Wayland.
Basically by setting 1/3 as the max splash size, a Wayland desktop with
no scale ratio will have a splash taking a third of the screen while it
would take 2/3 of the screen with a scale ratio of ×2 (of course, it
will still be very broken with a scale ratio of ×3 but are there
displays needing such high scaling?). The real fix will be when GTK/GDK
fix their API so that it returns what the docs says it should (i.e. a
size in "application pixels" not "device pixels"), as it does on X11,
Windows, macOS… Then we won't create random max size and we will be able
to properly control our splash size.
Note that this neither fixes nor works around the position issue on
Wayland (in my case, the splash was just always on top-left of the
display).
These small glitches have bothered me for a while now, so I finally
fixed these before the dev release!
Basically there were 2 fixes:
1. use the ink extents to compute any drawn area as this is what will be
actually drawn.
2. Not only expose the drawn area of the new text, but also the one of
the previous text in order to be sure all text pixels are correctly
reset (in case the new text is smaller than previous one). I.e. we
must expose the smallest rectangle containing both previous and new
area of text.
When loading a theme on Windows we always get an error like:
themes_theme_change_notify: error parsing [path including drive letter to:]\theme.css: theme.css:8:99Failed to import: Operation not supported
The location points to the end of the filename of the first @ import url string.
This is caused by the string not being an url.
Based on suggestions from Jehan and lillolollo we replace g_file_get_path
with g_file_get_uri since an url is what is expected here.
Since that function already escapes the string we also remove
g_str_escape here.
Orientation is now handled by core code, just next to profile conversion
handling.
One of the first consequence is that we don't need to have a non-GUI
version gimp_image_metadata_load_finish_batch() in libgimp, next to a
GUI version of the gimp_image_metadata_load_finish() function in
libgimpui. This makes for simpler API.
Also a plug-in which wishes to get access to the rotation dialog
provided by GIMP without loading ligimpui/GTK+ (for whatever reason)
will still have the feature.
The main advantage is that the "Don't ask me again" feature is now
handled by a settings in `Preferences > Image Import & Export` as the
"Metadata rotation policy". Until now it was saved as a global parasite,
which made it virtually non-editable once you checked it once (no easy
way to edit parasites except by scripts). So say you refused the
rotation once while checking "Don't ask again", and GIMP will forever
discard the rotation metadata without giving you a sane way to change
your mind. Of course, I could have passed the settings to plug-ins
through the PDB, but I find it a lot better to simply handle such
settings core-side.
The dialog code is basically the same as an app/dialogs/ as it was in
libgimp, with the minor improvement that it now takes the scale ratio
into account (basically the maximum thumbnail size will be bigger on
higher density displays).
Only downside of the move to the core is that this rotation dialog is
raised only when you open an image from the core, not as a PDB call. So
a plug-in which makes say a "file-jpeg-load" PDB call, even in
INTERACTIVE run mode, won't have rotation processed. Note that this was
already the same for embedded color profile conversion. This can be
wanted or not. Anyway some additional libgimp calls might be of interest
to explicitly call the core dialogs.
While this issue was unseen so far on common desktop machines, the CI
build encountered it, hence failing 6 of the unit tests.
A connection to the bus could not be established hence the dbus_manager
was never allocated, and finally it would crash at exit if we tried to
unref it unconditionnally. Use g_clear_object() instead.
Also add some stderr output for easier debugging, for when one of the 2
possible error cases might happen (as documented by g_bus_own_name()).
Tested in a VM. Minimized window is properly deiconified and showed to
the front. Though a window in the back (not minimized) is not moved to
the front.
GimpDisplay contains only the ID logic and the "gimp" and "config"
pointers, and lives in the core.
GimpDisplayImpl is a subclass and contains all the actual display
stuff. The subclass is only an implementation detail and doesn't
appear in any API.
Remove all hacks which pass displays as gpointer, GObject or
GimpObject through the core, or even lookup its type by name,
just use GimpDisplay.
Turn all ID param specs into object param specs (e.g. GimpParamImageID
becomes GimpParamImage) and convert between IDs and objects in
gimpgpparams.c directly above the the wire protocol, so all of app/,
libgimp/ and plug-ins/ can deal directly with objects down to the
lowest level and not care about IDs.
Use the actual object param specs for procedure arguments and return
values again instead of a plain g_param_spec_object() and bring back
the none_ok parameter.
This implies changing the PDB type checking functions to work on pure
integers instead of IDs (one can't check whether object creation is
possible if performing that check requires the object to already
exist).
For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is
not involved in automatic object creation magic at the protocol
level. Added wrappers which still say gimp_foo_is_valid() and take the
respective objects.
Adapted all code, and it all becomes nicer and less convoluted, even
the generated PDB wrappers in app/ and libgimp/.
GimpConfigWriter contains several constructors with the convention
`gimp_config_writer_new_* ()`. This will lead to problems however with
languages like Vala, where it cannot disambiguate the following:
```
// calls config_writer_new_string()
Gimp.ConfigWriter w = new ConfigWriter.string("xxx");
// calls config_writer_string()
w.string("xxx")
```
Using `from_` in constructors is general practice in GObject-bsed
libraries because of this.
This also fixes an error when trying to use vapigen on the GIMP .GIR
file.
which means that it's now included normally via gimpbase.h
and not any longer via gimpbasetypes.h which we only did out
of lazyness. A *lot* of files in libgimp* and app/ now need to
- libgimpbase: change GPParam to transfer all information about the
GValues we use, in the same way done for GPParamDef. GPParam is now
different from GimpParam from libgimp, pointers can't be casted any
longer. The protocol is now completely GimpPDBArgType-free. Remove
gp_params_destroy() from the public API.
- libgimp: add API to convert between an array of GPParams and
GimpValueArray, the latter is now the new official API for dealing
with procedure arguments and return values, GimpParam is cruft (the
wire now talks with GimpPlugIn more directly than with the members
of GimpPlugInInfo, which need additional compat conversions).
- libgimp, app: rename gimpgpparamspecs.[ch] to simply
gimpgpparams.[ch] which is also more accurate because they now
contain GValue functions too. The code that used to live in
app/plug-in/plug-in-params.h is now completely in libgimp.
- app: contains no protocol compat code any longer, the only place
that uses GimpPDBArgType is the PDB query procedure implementation,
which also needs to change.
- app: change some forgotten int32 run-modes to enums.
There are no replacements. Just we must make sure that all GTK+/GDK
calls are run from the main thread, which is already what we were doing.
Actually I don't even think these were doing anything as we were not
calling gdk_threads_init() so the default lock functions were not set
anyway. These were just bogus calls.
Step one: get rid of all those deprecation warnings that make
it hard to see any other warnings:
- add a lot of dummy API to GimpAction, GimpActionGroup, GimpUIManager
etc. which simply forwards to the deprecated GTK functions, they
will all go away again later
- rename GimpAction to GimpActionImpl
- add interface GimpAction that is implemented by all action classes,
creates a common interface and allows to remove some duplicated
logic from GimpToggleAction and GimpRadioAction, and at the same
time adds more features
Include the system-wide gimp.css file, in addition to the user-
specific gimp.css file, in the generated theme.css file, instead of
copying the former into the latter when creating the user's
gimpdir. This allows us to modify the system-wide gimp.css file,
and having the changes take effect in existing installations.
The GUI implementation of gimp_wait() relies on the ability to run
plug-ins (namely, the busy-dialog plug-in) without entering the
main loop. This prohibits the said plug-ins from making any PDB
calls, which would result in a deadlock. However, we're currently
calling gimp_gimprc_query() to fetch the prefer-dark-theme option
during gimp_ui_init() (or any time the theme.css file changes).
Instead, communicate this preference through the theme.css file
itself, by writing a /* prefer-dark-theme */ comment to the file
when the option is set. Yes, it's a bit of a hack :P
When an error occurs, we want to prevent overwriting any previous
version of the file by incomplete contents. So run
g_output_stream_close() with a cancelled GCancellable to do so.
See also discussion in #2565.
I had this funny behavior when I was quitting GIMP with the active tool
using modifiers (for instance bucket fill). Each time I'd quit with
ctrl-q (and if the image is not dirty), the options would use the value
from the modifier state and be saved as-is. Hence at next restart, the
default value was always different!
In the GUI implementation of gimp_wait(), explicitly finish the
input-pipe async operation after the busy-dialog plug-in
terminates, to avoid the async callback function from being
repeatedly called, stalling the main thread. Previously, this code
relied on gimp-parallel implicitly aborting the async operation,
but this is no longer the case since commit
4969d75785.
... 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.
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.
Remove the "independent" parameter of gimp_parallel_run_async(),
and have the function always execute the passed callback in the
shared async thread-pool.
Add a new gimp_parallel_run_async_full() function, taking, in
addition to a callback and a data pointer:
- A priority value, controlling the priority of the callback in
the async thread-pool queue. 0 is the default priority (used
by gimp_parallel_run_async()), negative values have higher
priority, and positive values have lower priority.
- A destructor function for the data pointer. This function is
called to free the user data in case the async operation is
canceled before execution of the callback function begins, and
the operation is dropped from the queue and aborted without
executing the callback. Note that if the callback *is*
executed, the destructor is *not* used -- it's the callback's
responsibility to free/recycle the user data.
Add a separate gimp_parallel_run_async_independent() function,
taking the same parameters, and executing the passed callback in
an independent thread, rather than the thread pool. This function
doesn't take a priority value or a destructor (and there's no
corresponding "_full()" variant that does), since they're pointless
for independent threads.
Adapt the rest of the code to the changes.
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.
Add a GimpGui::wait() virtual function, and a corresponding
gimp_wait() function. The function takes an object implementing
the GimpWaitable interface, and a printf-style message, and waits
for the object to become ready, displaying the message as
indication in the meantime. The default implementation simply
prints the message to STDERR.
Implement the function in gui-vtable, using the busy-dialog plug-
in added in the previous commit, to display the message in a
dialog. Additionally, if the object implements the GimpCancelable
interface, provide a "cancel" button in the dialog, which, when
pressed, causes gimp_cancelable_cancel() to be called on the
object. Note that the function keeps waiting on the object even
after requesting cancelation; GimpTriviallyCancelableWaitable can
be used to stop the wait once cancelation has been requested.
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.
Allow propgui constructors to specify an (optional) callback function
when creating pickers, to be called when a color/coordinate is picked,
similarly to controller callbacks.
Implement picker callback support in GimpFilterTool. When the active
picker has an associated callback function, call it instead of the
class's color_picked() function.
Add lots of "#include <gegl.h>" to .c files that miss it, which is
now necessary, since this commit adds a Babl* parameter in
propgui-types.h.
Add a log handler so that GIMP can display errors outputted by GEGL.
Since third party code may run in threads and we have no control on
these, we have to be sure GTK+ code is run in a thread-safe way, hence
the usage of gdk_threads_add_idle_full(). This was the case here for
GEGL, and handling GEGL logs the same way as other GIMP logs would
result in crashes.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
Nobody has them anymore, and they are deprecated in GTK+ 3.x. This
also fixes all conflicting mnemonics except those I missed, but we can
fix them now.
Disable the new "automatic window tabbing" feature introduced on macOS
Sierra. It breaks GTK+ applications and we would need proper support for
this in GTK+ if we want to use it.
Some actions are not meant to be saved, in particular the
"windows-display-*" which have only a meaning during a same session
since display IDs are session-dependent. So let display deletion
happen first so that proper cleaning of action is done when writing
menurc.
Add GimpMenuFactory can always be found in a GimpDialogManager, use
gimp_dialog_factory_get_menu_factory() where we have a dialog factory
instead of accessing "global_menu_factory" or redundantly passing a
menu factory around where we already pass around a dialog factory.
Duplicate accelerators are not supposed to happen. It is not possible
to set them through the GUI in particular. Nevertheless
gtk_accel_map_load() would apparently let duplicates pass, which could
happen after editing the menurc directly, or using the development
version (no action name migration happens there), or simply after a
potential bug. This is then very annoying because you may see several
actions displaying the same shortcut but only one actually work. And
trying to re-set through GUI the shortcut to the one action you wish to
run does not fix the duplicate issue (you have to laboriously find which
other action use the same accelerator and delete it first).
Better be safe than sorry and make a quick check at startup, then delete
the accelerator on one of the duplicates (you can't guess which one was
actually wanted, but at least you will facilitate manual reset through
the GUI).
Startup functions can now make the progress bar pulse in order
to report that something of unknown duration is in progress.
Call status_callback (NULL, NULL, same_percentage)
Create GIMP_CONFIG_DEFAULT_(ICON_)?THEME in gimpguiconfig.h to set
defaults in a single place, except for libgimpwidgets/ which cannot
include from app/.
file-procedure.[ch] is gone and its functions moved to
GimpPlugInManager where they belong (the manager keeps around the
lists of load, save and export procedures).
Utility functions from file-utils.[ch] that have nothing to do with
image files moved to core/gimp-utils.[ch].
Add gimp_stock_set_icon_theme() which can be called at any time, also
before gimp_stock_init(), in which case we avoid setting the configured
icon theme twice on startup. Call it from libgimp/gimpui.c and
from app/gui/icon-themes.c so the app and plug-ins use the same
icon theme.
Add gimp_image_import_color_profile(), a GUI vtable entry
query_profile_policy() and a new dialog which returns the profile
policy and the profile to convert to. Get rid of the wrapper that
calls the lcms plug-in for that dialog, the plug-in is now completely
unused.
This commit doesn't add any new features, it's just the former lcms
plug-in dialog implemented in app/ (except the little fix that it is
now aware of linear vs. gamma images).
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.
- use G_FILE_CREATE_NONE instead of 0
- don't put "Could not open <file> for writing: <error>" around the
returned error, the returned message is already verbose
gimp_directory_file(), gimp_data_directory_file() etc. The new
functions take a variable list of path elements to the file,
the list has to be NULL-terminated. Remove the newly added
gimp_personal_rc_gfile(). Start using the new functions in app/.
We need to mount every non-native GFile's volume, regardless of
whether the file procedure uses GIO directly or needs file-remote to
download/upload the file. Move the entire mount logic to a new
file-remote function and change gimp-gui.c and gui-vtable.c to only
return a GMountOperation. Try to mount every non-native file in
file-open.c and file-save.c and bail out if mounting fails. Simplify
the uploading and downloading code accordingly.
