Certain cloud providers return a blobname
rather than the actual filename with
g_file_get_uri (). Since our code only checks
the suffix and extension of non-native files,
we received "Unknown File Type" when
trying to load images from those providers.
This patch replaces g_file_get_uri () so that
we get the display-name instead, which
should always have the extension. This
may be changed in the future when we
switch to a FileChooser portal.
This same pattern is also used on the
GimpThumbBox so we see the display-name
rather than the blob name.
Thanks to Khalid Abu Shawarib for the
additional information!
...trying to get index.
When changing images or detaching a Colormap dockable,
we may temporarily not have a selection when the GUI
actions update. This patch adds a check to confirm we
have a valid selection before trying to get an index
from it.
These were missing help ids and don't have tooltips either, while some
of these actions may not be clear to end users what they do.
This will allow us to have context sensitive help about these commands
in the manual.
I've tested lightly this removal. I don't think this code was really
needed or logical anyway, though maybe I am missing something because I
barely discover the existence of this "Image Selection" feature of dock
windows!
As noted by Thomas Manni, editing NDE filters was still affected by
restrictions on existing layers, even if the edited layer did not have
those restrictions.
This patch alters gimp_item_tree_view_effects_edited_clicked () so that
it checks if the edited filter's drawable is visible or pixel locked,
rather than the currently selected layers. It also adds checks in
GimpFilterTool tool to verify an existing filter is being edited before
preventing certain operations.
This makes the range handles for the Levels tool and other
auto-generated range widgets adapt to any theme color,
just like the Gradient Editor range handles currently do.
This patch creates a gimp_colormap_selection_colormap_changed ()
function that gets the new colormap count and updates the entries
and spinbutton maximum in the Colormap Selection widget.
Previously the palette view was being refreshed, but the rest of the
widgets in the dialogue were not being updated to match when a
new color was added.
While they work well, the gegl_node_get_bounding_box ()
call causes the entire filter stack to refresh
each time we need to update the filter stack.
This slows down rendering significantly.
For 3.0 RC1, it's better to have good performance
and deal with the less common crop
issue for now. We'll work to find a better
performing solution for 3.0.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
This was bothering me that we were keeping these macros marked as legacy
in our public headers. Now they aren't so we can delete the whole file
when we'll finally get rid of all usage later, without breaking API.
Currently the search feature in the Layer dockable is also visible on
the Paths and Channels dockable as well. However, it has hardcoded
strings that refer to layers, and it uses gimp_item_list_get_items_by_substr ()
which only works on layers. We should hide it for 3.0RC1 and implement
it for the other two ItemTreeView children afterwards.
GimpControllerEditor's "Select Controller Event Action" dialogue has
a border around the standard icon. This is because it uses a GimpViewableDialog,
which normally shows the current image or layer as the right side icon (and thus
needs a border to potentially distinguish).
Since this is a special case, this patch retrieves the GimpViewRenderer for the icon
and then sets the border color to transparent.
As reported by Anders in !1919. This is because
gimp_pdb_execute_procedure_by_name() now expects a proper GimpArray for
float and int arrays, not a C array preceded by a size value.
Commit abf0c1c272 fixed the inconsistency of showing "R" for RGB's Red
channel selected whereas the actually displayed selection UI was "H" for
HSV's Hue channel.
As a consequence of this fix, now we were indeed displayed "R". Yet
people got used to working with the Hue channel (and LC plane) for
at least a dozen years. Let's make "H" the officially displayed channel.
Previously filters were cropped to the layer size in the
"crop_before" node. This was fine when we had destructive-only
filters, but now that we can multiple active layers, this causes
new layers to crop the prior ones if they're larger than the layer
(e.g. If gegl:drop-shadow goes out of the layer boundaries)
This patch sets the crop_before to the current sizes, then searches
the filter stack to see if there's a filter that needs a larger width
or height (or if it needs a smaller x or y values), then sets the crop
to that size. This crop update is also run when a filter is raised or
lowered.
The Fade curve is meant to use the widget's foreground color. The current
code detects this by checking if the curve's predefined color has an alpha
value of 0 - if it does, INPUT_COLOR (i) returns NULL and sends a NULL color
variable to gimp_curve_view_set_curve ().
However, since the GeglColor port, the "color" variable is an empty
GeglColor object rather than a pure NULL value. Thus, the line was always
drawn with the default GeglColor value which is difficult to see in light mode.
This patch adds a tertiary conditional statement so that a pure NULL is sent if
the alpha value is 0, rather than the color variable.
The Default box.vertical style covers up
the Sample Point indexes that are drawn
with Cairo. This patch adds a style for the
GimpSamplePointEditor that sets its inner
box.vertical to transparent in order to
to make the indexes visible.
In particular, palette's colors will want to be shown in their own space
(which may in fact be the image's space, for indexed image's colormap;
or in various spaces for named palettes).
gimp_brushes_popup() was triggering a popup allowing to change not only
the brush, but also the "paint mode", the opacity and the spacing. As
far as I could see, this was used nowhere for the paint mode and
opacity.
As for the spacing, it looks like gfig was indeed getting this data,
except that the GimpBrushSelect was disabling the effect on this scale
by setting change_brush_spacing to FALSE when calling
gimp_brush_factory_view_new(), and even setting this to TRUE, it was not
working fine anyway. Rather than debugging this, let's simplify the API.
Such settings seems like additional paint settings which don't have to
be in the brush selection. If someone wants people to also select an
opacity, spacing or paint mode, it would be much more efficient to add
separate plug-in arguments for these.
Additionally, I fix GimpBrushFactoryView not to show the spacing scale
when change_brush_spacing was set to FALSE anyway. This is just a bogus
widget then, which can only confuse people.
The colors are assumed to be sRGB since they come from a
pre-defined array and are used for the item color tags in the
GUI. This replaces the call to gimp_rgb_composite () with the
direct implementation of the GIMP_RGB_COMPOSITE_NORMAL
code.
It also ensures that only one call is made to gegl_color_set_rgba (),
rather than two if the color is inherited.
… more robust.
GIMP_PARAM_NO_VALIDATE and GIMP_CONFIG_PARAM_DONT_COMPARE were the same
value, most likely because when GIMP_CONFIG_PARAM_DONT_COMPARE got added
(commit c5c807d191), the comment to keep in sync
libgimpbase/gimpparamspecs.h and libgimpconfig/gimpconfig-params.h was
missed.
Instead, since libgimpconfig can include libgimpbase, do the other way
around: first non-GLib param flags are in libgimpbase, then we add a
GIMP_PARAM_FLAG_SHIFT, then we increment from it in libgimpconfig, and
finally we increment from GIMP_CONFIG_PARAM_FLAG_SHIFT if ever we add
more flags in app/ (right now GIMP_SYMMETRY_PARAM_GUI is apparently the
only one, but this may change).
The color for the nib handle is pulled from
the widget's background-color style.
However, this was not defined - so it was
always (0, 0, 0).
This patch adds a GimpBlobEditor CSS
class and defines the background and
border color for it to resolve the issue.
I had this one case at GIMP exit where destroying editor->selection
inside gimp_colormap_editor_set_context() was segfaulting, very likely
because the widget was already destroyed so the pointer was dangling.
Therefore set a weak pointer, and clear it in dispose, so that whatever
comes first at destruction time will reset the pointer to NULL.
As Cheesequake noted in !1673, there may be cases where one would want
to run gimp_help_connect() while also setting a tooltip. So they also
run gimp_help_set_help_data(), even though the latter is implied by the
former. Worse, it makes the order matter too much because if you call
gimp_help_connect() after gimp_help_set_help_data(), the tooltip would
be removed.
Now the reason is that gimp_help_connect() was clearly made to be run on
windows whereas gimp_help_set_help_data() was for other widgets, which
usually don't need to react to F1. Yet the previous commit does add
F1-connect for the lock buttons, which kind of makes sense. So why not
just add this tooltip argument.
As a side fix, I am removing a bunch of gimp_help_connect() on each
button in the layers effect popover. Just run it once on the top
container.
This patch adds gimp_help_connect () calls before
gImp_set_help_data () to set up F1 keybind to work
properly. It also adds lock_visibility_help_id to channel
view.
Resolves#11718
In GTK2 and GIMP 2.10, you can use the mouse scroller to
switch between dockable tabs if you hover over the bar.
This behavior was removed from GtkNotebook in GTK3.
This patch follows other GTK3 applications in re-implementing
the behavior with a scroll-event callback.
Liam was hitting Backspace on "histogram" which is an action section and
would likely not return a proper GimpAction through
gimp_action_view_get_accel_action().
Therefore let's make sure we initialize properly the action to NULL.
The submenu labels for tool-options-popup were
hardcoded as English in GimpToolOptionsEditor's calls
to the Save, Restore, and Delete Tool Presets buttons.
This meant that these menus always fail when called in
non-English UIs, since we compare the path name and
submenu labels to only load the correct submenu items.
This patch attaches the English labels to the submenu
object so that we can retrieve it for comparison in
gimp_menu_model_get_submodel ().
This is the only "language" from the list whose name is special and
should be localized at runtime, yet before we set any Preferences
language. It needs to be localized as the System Language itself which
will be run-dependant.
For instance, if your system is in French, it will be displayed as
"Langue système" but if you change your system to Korean, at next run,
it would show "시스템 언어". It is a per-run localization, independant
from the language selected in Preferences, and even less dependant from
build-time system language.
Unlike the GimpTranslationStore which can use a list of pre-localized
languages (each language in its own name), the GimpLanguageStore must be
displayed in the currently used locale.
Instead of always parsing the ISO-639 listing at each and every startup,
let's just generate the list of languages, their English name, and the
self-localized names as static struct.
This will just be much faster, and no worrying on the size of the XML
(or json) to parse.
We have translations for ckb (Central Kurdish), which is only
available in iso codes 639_3. For our language selection we only
parse 639(_2), which causes this language to show up as `??? (ckb)`.
This is of course not a good user experience since users need to know
that ckb is the abbreviation of their language.
We fix this by parsing `iso_639_3.xml` instead of `iso_639.xml`. This
works, but, since this file is a lot bigger, it takes a lot more time
(more than 1 second difference) to parse this.
Now, this is only done on startup, but this can certainly be a
noticeable delay.
… to keyboard input.
Removing a GtkBindingSet entry actually removes it from all GtkTreeView.
It's not limited to the ones contained in GimpContainerTreeView (which
makes sense, since it relies on the class) so it broke various
interactions across the software.
Let's just connect to signal key-press-event instead and block further
propagation. Not sure anyway why GTK has so many ways to handle key
interactions!
I'm also moving the implementation to GimpItemTreeView because this
enhanced keyboard handling is really about the items tree dockables
only, for the time being at least.
