Sometimes, you just want to quickly select layers, not necessarily save
the pattern. So you'd just type a few words, followed by Enter. Don't
save the search pattern everytime.
Only save it when you hit the "Save" button or on Shift-Enter.
We now save and load layer and channel item sets. Only missing set types
are path ones, but the whole path item is just its own exception in the
XCF format, and adding support for it, while keeping compatibility with
older XCF seem like a small headache. I could do it, but I actually
wonder if it is worth it. Would people really need to store sets of
paths?
Also this commit finally gets rid of any remnant of the old item "link"
concept (I think), so we are getting close to merging the branch.
I cleaned many remaining places where the concept of linked item still
survived.
On loading an XCF file with linked items, we are now going to create a
named sets for the linked items, allowing people to easily select these
back if the relation was still needed.
We don't remove gimp_item_get_linked() yet and in particular, we don't
save stored items into XCF files. This will come in an upcoming change.
- removing the GIMP_ITEM_SET_LINKED enum value.
- removing gimp_image_item_list_linked(). Now we should directly use
gimp_image_item_list_filter() instead.
- "preview-linked" option for transform tools is no more.
When double-clicking the non-selected layer, the function
gimp_view_renderer_set_border_color() was being called, which in turn
called gimp_view_renderer_update() after some idle time.
Unfortunately when this happened, the "update" handler
gimp_container_tree_store_renderer_update() would call
gtk_tree_model_row_changed() which triggers a focus out through GTK.
One way to handle this would be to call gimp_view_renderer_update()
directly when changing border color (no idle time), though it's actually
more efficient to just cancel the idle function when we start editing
the item name. It's just not necessary.
This got broken in commit 28f6b1b268 because you want to always throw
the signal. Yet the context must only be updated with a grid view in the
GimpContainerEditor. Now it should work correctly (hopefully!).
We must make sure to care about slight discrepancies between context
object and actually selected icon representing an object, which might be
slightly different at selection change time (just before everything
syncs up).
… for the case of data managed by the GimpContext.
Checking stable and dev builds, it looks this just never worked and used
to just show no selection. Now it is more annoying as it shows a
selected item, but not the right one. Just make sure it shows whatever
is currently selected.
The whole hack for types managed by context is not needed anymore. It
works fine with generic code. Also because of this hack, there was a bug
when clicking on some button raising a container popup (such as the
"Dynamics" button in tool options) would reset the context to default
value (e.g. reset to "Basic Dynamics") on the first click, without
raising the popup. Only the second click would raise a popup.
… GimpContainerComboBox and add a warning when the implementation is
missing.
Basically the default get_selected() implementation only works for
context properties, not for more generic usage of GimpContainerView. The
new warning will be a lot more informative and will help any future
cases where we might experience this bug.
This fixes the container entry never showing (e.g. brush/dynamics) names
because after commit ca3c480314, the class could not properly detect if
the selection changed (as default implementation for this virtual
function does not suit this subclass).
This prevents repeatitively running the same signals when it is useless.
In particular, I encountered a case of infinite loops between
"floating-selection-changed" and "select-items" ending up infinitely
calling each other (then crashing GIMP).
It's a bit ugly, but it's not like this is run many times (only once
when loading the icon theme, or changing it).
Fixes this error appearing in various unit tests' output:
> gimp_icons_sanity_check: Icon theme path has no 'hicolor' subdirectory: /builds/GNOME/gimp/_install/share/gimp/2.99/icons
(even though it was not a test-failure error, it's still better to limit
output for debugging)
… when appropriate icon failed to be found.
gtk_icon_theme_lookup_icon_for_scale() apparently does all standard
fallbacks, but not the last "image-missing" one which is supposed to
always be present. To avoid crashing, let's add an explicit fallback
ourselves.
We also encountered this on the test-ui unit test because icons are not
installed (but this could happen anyway when running GIMP normally with
third-party icon themes).
This should fix these errors when running `ninja test` or `make check`:
> GIMP-Error: Failed to open file ?/builds/GNOME/gimp/_install/etc/gimp/2.99/templaterc?: open() failed: No such file or directory
> GIMP-Error: Failed to open file ?/builds/GNOME/gimp/_install/etc/gimp/2.99/controllerrc?: open() failed: No such file or directory
When running tests, the data are not meant to be necessarily installed.
Therefore icons won't be found when calling gimp_widgets_init().
Add some special-casing to find them relatively to the install
directory.
An item with no path is actually not always a bug. It can very well be
normal if the tree view has a filtering logics where some items which
were selected suddenly get hidden.
The 3 available formats are: simple text search, regular expressions and
glob patterns (cf. previous commit). I did a small step back from
previous commit by getting "is-pattern" property back in GimpItemList
instead of having this case as a value of GimpSelectMethod. The reason
is that it would render a useless value in the Preferences combo box.
Text search is the default.
… search syntaxes.
The layer tree view is only using regexp so far, but the core code is
updated to allow more.
Simple text search is actually a bit more than "simple". It implies
tokenization of the text, Unicode normalization and case-folding. It
will also search with ASCII alternatives when possible. This includes
things like non-accented ASCII characters matching accented variants
which is neat.
Now it's not perfect. For instance tokenization seems very limited to
writing systems with spaces or alike. In particular, I tested with
Japanese and since you would typically write without spaces, a whole
group of several words would be one token. Since the text search
algorithm only search from token start, this is quite a failure as you
can't search with intermediate words only.
Will tweak them again later. It's just for a first version so that there
are no missing icons.
Unlike the Symbolic icons, the lock design is custom.
CC by-sa International 4.0.
