Drmingw already added its own exception handler which generates crash
traces in a text file, for plug-ins as well. This additional handler is
run after Drmingw handler and allows us to do things on our own, and in
particular we could display the content of the debug traces.
Right now it simply prints these to stderr, which actually won't be of
much use on Win32, first because the console is deactivated on stable
releases, also because after tests, it doesn't look like even running
GIMP from cmd outputs to console either.
We currently don't use the same debug dialog as the core on purpose,
because we don't want everyone to send us traces for every unmaintained
third party plug-ins out there. But we should definitely allow easier
trace possibilities at some point, first to improve/debug our own core
plug-ins, and also to help third party plug-in developers!
So this commit is not making visible changes yet but is actually a first
step towards these debugging goals.
When ending with gimp_quit(), GIMP was not displaying the "Plug-in
crashed" error dialog, which is not good, since we lose the crash
feedback for plug-ins. Just let the plug-in continue its normal run in
order to get the error dialog.
Also protect the tracing functions, which are not working on Win32.
SIGABRT was in the switch list in gimp_plugin_sigfatal_handler(), but it
had not been properly handled with gimp_signal_private(), making this
switch case useless. Fix this oversight, and while doing so, move it in
the "fatal error" list for which we may generate stack traces, similarly
to core signal handling. Indeed this signal can definitely happen during
various kinds of common bugs and needs to be debugged.
Similar to commit 845eb522b6, I had a CRITICAL which happened on a
device_changed, triggering gimp_display_shell_update_focus(), this time
in focus in.
Remove the connect_after() hack from GimpImageWindow again and instead
add gimp_display_shell_canvas_realize_after() and restore the configured
ruler visibility there. Should work for all cases now.
Commit fd6d4931c8 accidentally
introduced a bug that caused Wilber's eyes to misbehave. This
commit is an attempt to fix this issue. Unfortunately, it seems
like the bug can still be triggered through a certain sequence of
actions...
Add "ellipsize" property to GimpColorFrame and set it to
PANGO_ELLIPSIZE_END in the the pointer information dockable.
Better cut off long numbers than make them expand the dock.
Use the recently-added gegl_tile_handler_damage_rect() function
during GimpTileHandlerValidate invalidation, instead of manually
voiding the tile pyramid. This function avoids voiding mipmapped
tiles entirely when only a subarea of the tile needs to be redrawn.
See GEGL commit 3210f4ffc3c569a2acd9483811cb141070112bc6.
gimp_image_window_constructed(): connect_after to the notebook's
"switch-page" signal so gimp_display_shell_appearance_update() is
called after gimp_display_shell_canvas_realize(). Just another hack
to fix the hack...
If variables are edited directly, in some cases, the GUI and the
symmetries may end up out-of-sync. The variable can only be edited
through property setting.
This value is actually used as a special value when removing a guide to
get rid of a symmetry, in particular it is set in the guides' callback
gimp_mirror_guide_removed_cb() for "removed" signal.
If not setting to 0, when adding back a symmetry, it starts with weird
low or high values near to border (whereas when set to 0, it is reset to
default position afterwards).
Note that it might be a 2.10.0 RC2 instead. It will depend on whether we
decide to make a second release candidate (better process and safer) or
release earlier and go forward.
... parasite.
Not sure if that should be considered a bug. On one hand, it should
because that's core code. On the other hand, symmetry saving currently
uses parasites, which is a feature which can also be used by people
randomly. So "theoretically", there could be any data in a parasite and
we should not assume specific format.
Anyway still keep the error message but just print to standard error
output instead. Also print a bit more details (parasite name and
contents) as it would help for debugging when such a case were to occur.
Care for future changes of symmetries, by adding a version property. For
now, all symmetries are at version 0, and no real check is done. If any
symmetry bumps its settings in the future, it will have to override also
update_version() to change settings properly if necessary, according to
any new behavior.
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.
Add the color in gimp_smudge_paint(INIT) like GimpPaintbrush does.
Achieve this by calling gimp_palettes_add_color_history() directly,
not by inheriting GimpPaintbrush because GimpPaintbrush and GimpSmudge seem to share few common features.
We are not doing any write operation on this mask data so copying all
the data just to read it and unreffing it in the end is only a cost on
performance.
See also bug 694917.
When adding a rectangle to a projection's update area, align the
rectangle to a coarse grid, to reduce the complexity of the overall
area. We currently align the rectangle to a 32x32 grid, which
seems to be a good tradeoff between the overhead of processing a
complex area, and the overhead of processing a large area.
This keeps the same rectangle packing behaviour, so to behave exactly as
before for what concerns batching the updates, but should be lighter
when looping to find the first good rectangle to use.
In rtree_insert(), some conditions in the if tests are implied by
previous conditions. And therefore the 2 successive for loops are
actually identical.
In rtree_node_insert(), it is wrong/harmful to insert zero sized
rectangles in the tree because they can never be selected and just make
the list longer. So rtree_node_create() should just return NULL when w
or h are 0.
See bug 694917, comments 51 to 61.
