The markdown triple-quote (```) has to be on its own at the start of a
newline. Schumaml was telling me that too many reporters would paste
just after some text, which would therefore break the markdown syntax.
Instead let's add 3 newlines before the triple-quote, so that even
people who would not hit the "Copy Bug Information" button (but instead
select and copy) have a hint that these newlines are made on purpose.
Also add a comment (which is discarded by Gitlab) to make this even more
obvious.
Then even when pasting just after some text on the same line, the
triple-quote will end up on its own line.
(cherry picked from commit d3105e5c72)
… the container.
There was this weird case which we somehow could only reproduce on
Aryeom's computer/build, not mine, with the same code and reproduction
steps (reproducible at will on her build only). Basically when drag'n
dropping a duplicated layer inside a collapsed layer group, the
row-expanded handler would try to select the moved layer before it is
actually inserted. This would end up into crash-happy code.
I'm still unsure of why the order of operation is different here, but
anyway what is for sure is that the `inserting_item` boolean flag was
not protecting much. It's not like it's an actual mutex and anyway this
is not multi-threaded code either so this flag was mostly useless (which
is why we were crashing). Instead let's actually look if the item is in
the container or not.
With my previous commit, I improved the search action display and search
algorithm (which was returning wrong results), but we had lost showing
the non-sensitive reason in menu item tooltips. This fixes it, by
actually appending the reason, but only in the end, on the GtkWidget
tooltip (not in the action's tooltip itself).
(cherry picked from commit 13a02aea23)
The color space label may be a bit long (depends on profile title which
may just be anything and we don't control it), so I allow it to wrap.
The file path on the other hand would not work well with wrapping. It
already has ellipsis in center, but GTK always gives the max size it can
as a default. So if the file is even just slightly deep in the file
tree, we end up with extra-wide Image Properties dialog.
My trick is to give a sensible max size at dialog creation (25
characters max) but to disable this max size as soon as the window gets
realized, hence allowing the label to actually grow up to the contents
actual max size, were one to manually resize the window.
(cherry picked from commit 377de0a65b)
"RGB color" is not a color space, only the model. To get full color
space information, we want to display the model and associated profile
name.
Of course, the "Image Properties" dialog also has a tab displaying
details about the color profile. Still it's better if the general info
displays not too wrong label contents.
Note: when the used color profile has no name, it will show "(unnamed
profile)" which is still more informative than just the color model.
(cherry picked from commit b9ab461977)
It looks like GDK motion hints are broken, at least on X, causing
us to drop motion events in GimpSpinScale, if the motion triggers
an operation that blocks the main thread for a significant amount
of time, such as projection invalidation.
Instead, disable motion hints for spin-scales, and use an idle to
perform ad-hoc motion compression.
Add a new "Messages" boolean parameter to performance logs, which,
when set, records GLIB log messages in the performance log as
markers, with an accompanying sample capturing their backtrace.
This option is enabled by default.
(cherry picked from commit 9e0fdc8e2c)
Add an option to record progressive performance logs. Progressive
logs contain complete information after each recorded sample, by
writing partial address maps at each sample, containing all new
addresses introduced by the sample. Furthermore, when recording a
progressive log, the output stream is flushed after each sample.
This allows recording complete logs even in cases where they can't
be properly terminated, such as when GIMP crashes or freezes in the
middle of the log.
Progressive logs are disabled by default, since they potentially
increase the sampling cost. They can be enabled through a toggle
in the log file-dialog, or through the
GIMP_PERFORMANCE_LOG_PROGRESSIVE environment varaible.
(cherry picked from commit 146c234350)
When recording a performance log, allow setting the log parametrs
through the file dialog. Currently, this includes the sample
frequency, and the option to include backtraces.
These options are still controllable through the
GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY and
GIMP_PERFORMANCE_LOG_BACKTRACE environment variables. When set,
the variables override the values entered through the UI.
(cherry picked from commit 126002c5c9)
In GimpToolButton, when in "show menu on hover" mode, increase the
idle priority for hiding the the tool-group menu upon button/menu
leave-notify. Make the priority one step below the normal event
priority, so that a subsequent button/menu enter-notify event
canceling the idle is processed beforehand, while the idle is
otherwise still processed before ordinary lower-priority sources,
in particular, before projection rendering timeouts.
In gimp_tool_button_enter_notify(), only mask-in the mouse-button
state for determining whether to show the tool-group menu. This
avoids other bits of state -- in particular, certain keyboard
locks, including keyboard-layout state -- from preventing the menu
from showing.
... which sets the limits of the range-widget's handle-bar
explicitly, instead of using the lower/upper properties' limits.
(cherry picked from commit ce8235e977)
In GimpHandleBar, add gimp_handle_bar_{set,unset,get}_limits(), to
allow settings the handle-bar limits explicitly, rather than
inheriting the adjustment limits.
(cherry picked from commit fa5dd99559)
... which creates a widget controlling a pair of lower/upper range-
limit properties, comprised of a handle-bar and two spin-buttons.
If the "sorted" parameter is TRUE, the "lower" property is bounded
above by the "upper" property, and vice versa.
(cherry picked from commit e03b8e597b)
... which takes a pair of GtkAdjustments, and binds the value of
the first to the lower-limit of the second, and the value of the
second to the upper-limit of the first.
(cherry picked from commit 45e5c2231a)
In tool-group GimpToolButton tooltips, in addition to showing the
description of the currently-active tool, list the other tools in
the group as well, to improve discoverability.
(cherry picked from commit 4d83c7a3fc)
Add a new GimpAccelLabel widget, which shows an accelerator label
for a given GimpAction. Unlike GtkAccelLabel, GimpAccelLabel
doesn't show a user-provided label in addition to that.
Note that the size request of GtkAccelLabel doesn't include the
accelerator part, which is desirable in some contexts.
GimpAccelLabel doesn't suffer from that.
(cherry picked from commit 2259ad5fcc)
Wherever we store arbitrary-format colors in an opaque buffer, use
double for the buffer, instead of char, so that it has a strict-
enough alignment to handle all our used pixel formats.
(cherry picked from commit a90f59d961)
gegl:focus-blur blurs the image around a focal point. It can be
used to create fake depth-of-field effects.
Add a prop-gui constructor which uses a FOCUS controller to control
the focus geometry.
(cherry picked from commit 60d4d25b93)
There is no non-hackish way of fixing this without adding a new
"use-opacity-paint-mode" property to GimpToolPreset and a new toggle
in GimpToolPresetEditor. Restoring opacity and paint mode can now be
controlled explicitly, and defaults to TRUE.
(cherry picked from commit 97b714d428)
If we don't do this, the clipboard owner doesn't get unreffed (also the
GtkClipboardClearFunc is not called either, but we don't set any so this
was not a big problem).
The main consequence was that copying was setting the Gimp object as an
owner, which kept a reference and prevent its finalize() method to run,
hence was leaking data (and in particular some GEGL buffers for
clipboard operations, which was how the issue became more visible upon
exit).
(cherry picked from commit fca6371e29)
When building (at least on 32-bit), fixes this warning:
> app/widgets/gimpdashboard.c:3840:58: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Unsigned long long is specified in the C99 standard to be at least
64-bit. So it's normal that the compiler complains, as a cast from
unsigned long long to a pointer has chances to go very wrong.
Yet gimp_backtrace_get_frame_address() actually returns a guintptr which
is type-compatible with gpointer so let's not give the compiler false
information and just use this type. Then cast it to unsigned long long
just for printing to dashboard log.
(cherry picked from commit 8caef4ea0b)
In GimpToolButton, don't let the group menu grab the keyboard focus
when showing it on hover. This avoids accidentally reassigning the
keyboard shortcut of the selected tool.
Apparently, the "drag-begin" signal of dockbook tabs can be raised
multiple times when a drag begins (this seems to happen randomly,
and rarely -- possibly a GTK bug). In
gimp_paned_box_drag_callback(), which gets called in response, make
sure not to leak the corresponding idle source in this case, which
can lead to a segfault if the widget is destroyed before the idle
is run.
(cherry picked from commit 6bae5d8cf7)
Add a "Menu mode" option to the toolbox preferences, which controls
the menu behavior for tool-group buttons, and can be one of "Show
on click" (current behavior), "Show on hover" (show the menu when
hovering over the button), and "Show on hover in single column"
(behaves like "Show on hover" when the toolbox has a single column,
and "Show on click" otherwise) -- the latter is the default.
Note that "Show on hover" requires the ability to remove the menu
grab, which doesn't seem to work in GTK3, so this change is
restricted to 2.10 for now.
In GimpSpinScale, apply the slider gamma to the input [min,max]
range, rather than the output [0,1] range, using an odd gamma
curve, in particular, so that we handle negative values correctly.
(cherry picked from commit 5678153797)
In GimpFgBgEditor, we currently use gtk_render_frame() in master,
and gtk_paint_shadow() in gimp-2-10, to draw a border around the
color FG/BG color areas. However, the former is relatively
subtle, especially with dark themes, and the latter is a NOP with
the pixmap engine, which is what our built-in themes use.
Instead, draw the border ourselves as a pair of black and white
rectangles, similarly to Photoshop.
Move the entire color-frame drawing functionality to a separate
function, to avoid code duplication between the FG and BG frames.
(cherry picked from commit fb1c086097)
gtk_widget_get_window() may return NULL. I had the case when opening
some menus in bottom of tool options (like the "Save|Restore Tool
Preset" menus). We must check this before doing anything with it.
(cherry picked from commit 0a28534a90)
Previously we were only passing this information on the debug dialog
when debugging warnings and criticals. Now it will also have the
information for crashes, hence recommending people to update their GIMP
instead of reporting bugs on old versions.
(cherry picked from commit 5b664ecbec)
Instead of making the focus on bug reporting, the debug dialog will now
make the focus on updating the application if it is found that one is
not using the last version.
Debug data (backtraces and co.) will still be available and copiable,
but under an expander, and bug report button won't be displayed (i.e.
data will still be available upon request but we don't push anymore
people to submit it directly if they are using old versions of GIMP).
Of course, if you are using the last version (or version check was not
possible), the dialog still stays the same.
(cherry picked from commit 2f379494a7)
