Fixes:
> (file-svg:125356): Gtk-CRITICAL **: 22:11:43.459: gtk_entry_buffer_set_text: assertion 'chars != NULL' failed
… when running file-svg-export because the default of the "title" string
argument is NULL.
I did hesitate considering this was a bug in file-svg code on the
premises that a NULL value was not valid (hence replacing it as ""), but
in the end, I went with the more flexible solution, which is that NULL
is considered equivalent to "". So GimpLabelEntry code will just
transform the NULL pointer internally to an empty string.
There were 3 bugs which were kinda countering each other and
participating to some confusion regarding actual layer types to export.
First the previous commit as we were looking whether a layer had been
rasterized to determine the object type on libgimp side. Secondly this
commit as the plug-in was using the previously wrong procedures. Lastly
with the upcoming commit, when we were duplicating an image, we were
disregarding any rasterization.
Without this, libgimp was creating raster GimpLayer objects when these
had been rasterized, which only made kinda sense when the old "discard"
procedures were not reversible. Yet even this was not entirely true,
since it was still possible to undo, but unfortunately these objects are
long lived. Once you get a GimpLayer, it won't ever change into a
GimpTextLayer (or others)!
So we need to have an object of the correct child type then we'll use
gimp_rasterizable_is_rasterized() to decide how to make use of the
object.
Commit 6874c47544 was not correct as we generate some type/values
description, extensively using Pango markup.
This additional fix does not change the logic from the aforementionned
commit, which is that the blurb still is just plain text (nor markup),
which we properly escape to display as-is, mixed with Pango markup.
Based on the label, and also "retrieve" was just too generic. It made
sense in the context of rasterizable items, but with the more generic
"layers" context, it would raise uncertainty.
I did wonder if it was supposed to be markup, and after a bit of test, I
could confirm that adding random markup in some other arguments, it does
sometimes styles the text, and other times, it just display the tags.
So I'm leaving an API warning to review this for GIMP 4.
This also fixes WARNINGs when a tag-like text is added:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/2469#note_2574483
Share the whole rasterize logic of the text, link and vector layer into
an interface. I didn't write it as an abstract parent class, because we
might have more rasterizable items in the future, which may not be
layers (e.g. there were discussions of vector masks).
Instead of using a makeshift search entry use the one provided by GTK.
As a side-product it allows the procedure browser to shrink its left
panel a little more.
The 'Plugin Browser' and 'Procedure Browser' use the same logic for
enforcing the minimum size of the details page and the list views. And
both are doing it by first setting the minimum: size of GtkTreeView and
then they climb up the widget tree to do the same. This is not ideal.
Setting the minimum size of GtkTreeView is not necessary because it is
inside of GtkScrolledWindow which makes this request moot. It also does
not enforce the minimum height of the widget for that reason. And if
GimpBrowser ever changes, both browsers will need to update their logic.
Moving the size enforcing a level up is logical and more robust.
Using an explicit value of width for the height of the dialog window
makes little sense. This makes the size of the dialog window clear.
And now the height of the list widget is set with its own macro instead
of piggybacking on the dialog window height.
