This fixes:
> app/core/gimpitemlist.c:632:7: warning: ‘g_pattern_match_string’ is deprecated: Use 'g_pattern_spec_match_string' instead [-Wdeprecated-declarations]
The new function appeared in GLib 2.70 which is our current minimum GLib
requirement, so the replacement is fine.
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.
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.
Instead of just storing list of layers, I created a new simple type
GimpItemList (actually GimpItemSet would be better named, but
unfortunately we use this name for an enum type). So far, this new class
can handle 2 types of item sets: named fixed sets and pattern-generated
sets.
