… deserialize with a wrong or unknown type.
The error message in issue #13787 was about trying to deserialize a
GimpControllerMouse object as GimpControllerInfo's controller. Yet
GimpControllerMouse was removed with commit 76ddf4421c so this was
failing.
With this change, such error would be more explicit, with an error
saying:
> Unknown object type: GimpControllerMouse
… instead of:
> unexpected character ')', expecting string constant
(which was very confusing to the actual issue)
libgimpbase:
- Mew GimpFileChooserAction enum type: basically a near-mapping of
GtkFileChooserAction (GTK is not accessible from libgimpbase) with
an added GIMP_FILE_CHOOSER_ACTION_ANY.
- New GimpParamSpecFile param spec type: based off
GimpParamSpecObject, it has a default value, but also a none_ok and
action argument. This way, we can also know from the argument type
if this is a file argument meant for selecting a normal file or a
folder, or for saving into a file, or for creating a directory.
libgimp, plug-ins:
- All existing file arguments (until now using a standard
GParamSpecObject param with GFile value type) were moved to the new
GimpParamSpecFile.
- Script-Fu in particular will now generate the appropriate param type
depending on whether it is an SF-FILENAME or SF-DIRNAME.
- File arguments are now stored between runs as a URI rather than as a
path. As far as I can tell, a GFile always has a URI, but not always
a path (in particular remote file won't have a path).
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.
GimpArray (and therefore the int32 array typedef) contains its own size.
We don't need to store the array size in a preceding argument.
Also adding gimp_int32_array_get_values() and gimp_int32_array_set_values()
to edit an existing GimpArray.
This comes with the fact we should start making the GimpArray type more
explicit, because clearly by trying to hide this type so much, it was
too much looking like the int32 array param spec was expecting a C array
(as was visible in the file-ico plug-in where we were getting a C array,
which was a bug only made invisible by the fact we were not setting the
C array back in the config object in the end).
Last but not least, I finally implemented int32 array (de)serialization.
As a side fix, the "images" arg in file-pdf-export-multi procedure is
now a proper image array (not an int32 array), and of course the "count"
arg was removed.
The purpose of this flag is to have some procedure arguments for which
you wish to ignore last values, or restored values. This may be needed
for arguments which are really volatile and likely won't survive a
session (or even from a run to another).
This will be used in my next commit.
Note: this is very close to GIMP_CONFIG_PARAM_IGNORE, except that this
latter is used for obsolete properties instead, so I felt that it may
not have been the best idea to mix these semantically different flag.
Also GIMP_CONFIG_PARAM_IGNORE properties are not serialized but they are
deserialized, which is not exactly what we want (in most case, it would
work the same, but it also means that if last-used values were to
contain some deprecated value for a property for which we added this
flag, there would be at least one run where a buggy behavior would
happen).
Rather than trying to implement full i18n plural support, we just remove
this failed attempt from the past. The fact is that to get proper
support, we'd basically need to reimplement a Gettext-like plural
definition syntax within our API, then ask people to write down this
plural definition for their language, then to write every plural form…
all this for custom units which only them will ever see!
Moreover code investigation shows that the singular form was simply
never used, and the plural form was always used (whatever the actual
unit value displayed).
As for the "identifier", this was a text which was never shown anywhere
(except in the unit editor) and for all built-in units, as well as
default unitrc units, it was equivalent to the English plural value.
So we now just have a unique name which is the "long label" to be used
everywhere in the GUI, and abbreviation will be basically the "short
label". That's it. No useless (or worse, not actually usable because it
was not generic internationalization) values anymore!
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes#10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
I also changed a bit the new color serialization by adding a (color …)
symbol framing the contents, for cases where we don't have a specific
property name, e.g. for the color history list stored in colorrc, unlike
for GimpConfig GeglColor properties.
While doing this, I moved GeglColor property deserialization code into
gimp_scanner_parse_color() which is now able to recognize both older
(color-rgb|rgba|hsv|hsva with no color space) and newer serialization
formats ("color", color model agnostic and space aware).
Some old config files will contain (color-rgb) contents. Also some data, such as
historical tool presets (.gtp files) will have such values in their
(tool-options).
There are 3 fixes here:
1. First, searching for "\"GimpFont\"" to determine whether or not this is a new
format text parasite is not enough, because this string can be found in a
text layer with "GimpFont" only as contents. It will serialize as:
> (text "GimpFont")
Instead search for "(font \"GimpFont\"" which cannot be created as part of
the text contents because of the unprotected double quotes).
2. We must verify that strstr() did not return NULL when searching for markup
delimiters. It may happen if the parasite contents is invalid (we must always
assume it can be, since it's user data).
3. When deserialization of a text from parasite fails (e.g. because parasite
doesn't actually exist or its format is wrong), still make sure the GimpText
has a font (setting the standard one before deserializing). Otherwise GIMP
crashes down the line.
For this, I also had to fix gimp_config_deserialize_object(): the object type
name must be parsed even if an object was already set in a GObject property.
I add a new class method deserialize_create() to GimpConfigInterface which
returns the GimpConfig object per deserialization, instead of modifying an
existing bare object.
This matters for cases like our GimpResource (and later our GimpItem) classes
which are fully managed by libgimp and should be unique objects per actual
resource. It should even be possible to compare the pointer itself for identity.
That's why we need to let GimpResource create the object (in reality request it
to the infra and only ref it) through this new class method.
With this commit and the previous ones, all GimpResource are now properly stored
as plug-in settings (e.g. the "film" plug-in has a font setting which is now
properly remembered).
These identifiers are not portable (across various installations and therefore
not for XCF either), but at least they are reasonably identifying data on a same
installation (unlike GimpResource's int ID which is only valid within a single
session) which makes them very fine for plug-in settings storage.
When a data file disappears, we fallback to the context default data instead.
Since the parsing failure I was experiencing was normal (not a bug), and
since I was not seeing error being passed down to deserialize(), I
assume this assert was always wrong. I hadn't realize that the GError
object was in fact populated by deserialized through g_scanner_error()
calls which were setting the GError passed at creation of the scanner
through a handler.
So there was indeed a bug in one of the functions called by our
deserialize() implementation. There was one failure case where the error
was just reported with g_warning() instead of g_scanner_error().
Now that it's fixed, I brought back the asserts (previous commits)
because the error object is actually always well populated.
Used for instance if a plug-in had a GimpParasite argument (or aux
argument), which might not seem too useful at first. But anyway we
propose the type, so let's support it properly.
And actually I am going to use it in the next commit as a trick to save
binary data in stored last values for a plug-in.
In gimp_config_deserialize_fundamental(), we can't use
g_value_set_static_string() because that will in the end pass the
GScanner's temporary scanner->value.v_string to
GObject::set_property(), and depending on set_property()'s
implementation, we might not dup the string (for example objects
created via gimp_config_type_register() will simply use g_value_copy()
and end up with a dangling pointer as a string member).
In gimp_config_deserialize_fundamental(), cast integer token values
to the target value type *before* negating them, to avoid
performing unsigned negation, which can result in a positive value
when cast to the target value type (in particular, when the target
value type is float/double).
If the enum value is not found among the nicks and names of the
GParamSpec's actual enum type, check if it has a "gimp-compat-enum"
GType attached as QData, and try the lookup there.
Use g_file_get_parse_name() and g_file_parse_name() in order to turn
them into strings and back. Not really sure if we will end up needing
this, but I need it for current hacking. It's clean code and easy
enough to revert, so no harm done in either case.
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
This fix is entirely sick, so is our method of serializing units,
which we write out as (unit foo bar) instead of (unit "foo bar"). The
assumption that caused this shit was that a unit's "identifier" is
really an identifier in the C-ish sense, when in fact it's just a
random user entered string.
Here, we try to parse at least the default units shipped with gimp,
and we add code to parse (unit "foo bar") in order to be compatible
with future correct unit serializing.
2009-01-17 Michael Natterer <mitch@gimp.org>
* all files with a GPL header and all COPYING files:
Change licence to GPLv3 (and to LGPLv3 for libgimp).
Cleaned up some copyright headers and regenerated the parsers in
the ImageMap plugin.
svn path=/trunk/; revision=27913
