summaryrefslogtreecommitdiff
path: root/json-glib/json-gobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Drop or mark unused parametersEmmanuele Bassi2022-10-111-6/+10
| | | | Avoid compiler warnings when running with `-Wunused-parameter`.
* Update the documentation for the GObject integration APIEmmanuele Bassi2021-06-101-41/+41
|
* Merge branch 'gidocgen' into 'master'Emmanuele Bassi2021-06-081-35/+26
|\ | | | | | | | | Use gi-docgen to build the API reference See merge request GNOME/json-glib!41
| * docs: Initial, rough port away from gtk-docEmmanuele Bassi2021-06-081-35/+26
| | | | | | | | | | | | | | | | | | | | Drop `SECTION` blurbs. Use gi-docgen syntax for internal links. Use summary lines for gi-docgen indices. Use Markdown syntax for code fragments.
* | trivial: Return the correct type in g_return_val_if_fail()wip/hughsie/typecheckRichard Hughes2021-05-161-4/+4
|/
* Use non-deprecated GObject constructor and typesEmmanuele Bassi2020-08-241-28/+23
| | | | | Both g_object_newv() and GParameter have been deprecated for a long time.
* Merge branch 'master-old'Emmanuele Bassi2017-07-101-13/+8
|\
| * core: Avoid json_object_get_members()Garrett Regier2017-06-161-13/+8
| | | | | | | | | | | | | | Use JsonObject's private members_ordered GQueue instead. This avoids a g_list_copy(). https://bugzilla.gnome.org/show_bug.cgi?id=773504
* | gobject: Ignore deprecation warning for g_object_newv()Emmanuele Bassi2017-07-101-0/+2
|/ | | | | We're going to replace it once we bump the dependency on GObject, to avoid a nasty ifdef hell.
* Use Unicode in translatable stringsPiotr Drąg2017-03-181-1/+1
| | | | | | See https://developer.gnome.org/hig/stable/typography.html https://bugzilla.gnome.org/show_bug.cgi?id=772753
* Fix translator commentsPiotr Drąg2017-01-281-1/+1
| | | | They need to be exactly one line above a string to show up in .po files.
* node: Add json_node_ref() and json_node_unref()Philip Withnall2016-03-011-2/+2
| | | | | | | | | | | | | | Add reference counting semantics to JsonNode, in addition to the existing init/unset and alloc/free semantics. json_node_free() must only be used with nodes allocated using json_node_alloc(). json_node_unref() may be used with all nodes (if correctly paired; it may be paired with json_node_alloc()). It is not valid to call json_node_free() on a node whose reference count is not 1. https://bugzilla.gnome.org/show_bug.cgi?id=756121
* Handle serialization/deserialization of glong gulong and guint64Tristan Van Berkom2014-12-301-0/+28
| | | | | | | | Long and unsigned long was properly serialized but not deserialized, guint64 handling is not ideal as the type is cast into a gint64, however this is better than not handling the fundamental type at all. https://bugzilla.gnome.org/show_bug.cgi?id=725972
* Remove conditional inclusion of config.hEmmanuele Bassi2014-03-181-2/+0
| | | | All the platforms and build system we support have a config.h header.
* docs: Port to MarkDownEmmanuele Bassi2014-03-181-2/+2
| | | | | Drop the DocBook documentation, and move everything to the MarkDown format used by modern gtk-doc.
* Remove compile time GLib version checkEmmanuele Bassi2013-08-211-8/+0
| | | | | We depend on a new version of GLib, so we can remove a bunch of old version checks.
* Use typed initializers for JsonNodeEmmanuele Bassi2012-10-271-63/+52
|
* gobject: Use JsonSerializable APIEmmanuele Bassi2012-10-261-7/+9
| | | | Instead of directly accessing the vfunc from the interface vtable.
* Use g_value_[sg]et_schar() with GLib ≥ 2.31Emmanuele Bassi2011-10-121-1/+9
| | | | The non-explicitly signed variant is deprecated.
* gobject: Deserialize CONSTRUCT propertiesEmmanuele Bassi2011-08-231-8/+5
| | | | | | | | | | | | While we have to give up deserializing CONSTRUCT_ONLY properties with JsonSerializable, CONSTRUCT properties should just be deserialized like any other property. Sadly, there's still a refuse in the json_gobject_new() code that skips CONSTRUCT properties along with CONSTRUCT_ONLY ones — a remnant of a period when we deserialized them both without JsonSerializable. https://bugzilla.gnome.org/show_bug.cgi?id=655526
* Handle integer to float/double conversions in json_deserialize_pspec()Tristan Van Berkom2011-07-311-1/+21
| | | | | | | It happens that while serializing that float/double properties are set to round numbers, this results in deserialization as gint64 values and a parse failure. This patch addresses it by accepting round gint64 numbers as valid values for float/double properties.
* Added an additional warning to json_gobject_new()Tristan Van Berkom2011-07-131-1/+6
| | | | | | The same warning that is fired when failing to deserialize properties normally needed to be added for the case that we fail to deserialize construct-only properties.
* Avoid serializing default property values only afterTristan Van Berkom2011-07-091-8/+2
| | | | | | | | consulting the JsonSerializable. This patch gives the JsonSerializable class a chance to decide whether it's appropriate to serialize a property before JsonGObject checks for a default value and skips the property.
* Fixed badly handled fundamental types in json_deserialize_pspec().Tristan Van Berkom2011-07-071-12/+30
| | | | | | | | This patch fixes json_deserialize_pspec() to return FALSE when failing to deserialize some properties. Consequently the patch ensures we get the intended warnings when failing to deserialize pspecs for some fundamental types: Failed to deserialize property "foo" of type "int" on object "bar"
* Mark GError messages for translationsEmmanuele Bassi2011-06-011-2/+2
| | | | These errors might find their way into a UI.
* Add i18n machineryEmmanuele Bassi2011-06-011-0/+2
| | | | We need to translate the GError messages.
* gobject: Do not serialize default valuesEmmanuele Bassi2011-06-011-0/+7
| | | | | If a property is set to its default value then we can skip its serialization, to keep the number of JSON object members down.
* serializable: Allow introspecting propertiesEmmanuele Bassi2011-06-011-9/+34
| | | | | This allows a Serializable implementation to override the property list, and the setter and the getter function.
* Fixed json_deserialize_pspec() to handle null nodes.Tristan Van Berkom2011-05-031-1/+13
| | | | This fixes deserialization to match serialization (bug 648539)
* Warn from json_gobject_deserialize() if a listed property cannot be ↵Tristan Van Berkom2011-04-231-0/+3
| | | | deserialized.
* gobject: Fix deserialization of construct-only propertiesEmmanuele Bassi2010-09-251-2/+2
| | | | | | | | Commit 2d7550948dfb2e5907b851bc2c4bd296a7526086 broke the construct-only properties; we now only check for the G_PARAM_CONSTRUCT_ONLY flag, and pass construct-only properties to g_object_newv(); all the properties flagged as G_PARAM_CONSTRUCT gets passed with the rest of the properties after that.
* debug: Add debug notes in the GObject codeEmmanuele Bassi2010-09-251-2/+12
|
* Add introspection annotationsEmmanuele Bassi2010-09-251-2/+2
|
* gobject: Use construct and construct-only propertiesEmmanuele Bassi2010-08-151-1/+1
| | | | | | | Right now, we're checking twice for G_PARAM_CONSTRUCT_ONLY, but what we really want is to check for both G_PARAM_CONSTRUCT and G_PARAM_CONSTRUCT_ONLY properties when creating a new instance from a JSON definition.
* Initialize out variables before using themVincent Untz2009-12-291-2/+2
| | | | | | | | | | | Here's a small patch for json-glib, to fix some gcc warnings breaking the build with -Werror (gcc can't know if the variable will get initialized or not). I didn't find a product for json-glib in bugzilla, but I guess a mail will work ;-) Happy holidays :-) Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
* docs: Fix annotation for json_gobject_to_data()Emmanuele Bassi2009-11-291-1/+1
|
* boxed: Split (de)serialization registrationEmmanuele Bassi2009-11-231-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A GBoxed type defined as: struct Boxed { int foo; gboolean bar; int baz; }; Can be represented either by a JSON object: { "foo" : 1, "bar" : true, "baz" : 3 } Or by a JSON array: [ 1, true, 3 ] The current function for registering a serialization and a deserialization pair does not allow registering more than one deserialization function - which means that there can only be one way to deserialize a GBoxed type into a specific JsonNode type. To allow having more than one JsonNodeType associated to a GBoxed type and a deserialization function we need to split out the registration of the serialization and deserialization functions into two distinct functions.
* serializable: Make Serializable in charge of parsingTristan Van Berkom2009-11-121-2/+5
| | | | | | | | | | | | | | If a GObject class implements JsonSerializable and has overridden the serialize_property() vfunc then the Serializable should be fully in charge of serializing a property - that is: JSON-GLib should not try to add a fallback in case the serialize_property() implementation returned NULL. This is a change in semantics for JsonSerializable implementations. http://bugzilla.openedhand.com/show_bug.cgi?id=1859 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
* gobject: Use from/to data naming conventionEmmanuele Bassi2009-10-281-4/+59
| | | | | | | | | | | | | | | | | | | | | | Be more GLib-like, and use <namespace>_<type>_from_data() <namespace>_<type>_to_data() Instead of the homebrew "construct" and "serialize", when dealing with string buffers. This means: • adding json_gobject_from_data() to deprecate json_construct_gobject() • adding json_gobject_to_data() to deprecate json_serialize_gobject() The json_construct_gobject() function also contains a mistake: it uses gsize with the special value of -1 meaning "slurp the whole string", but gsize is an unsigned type. The newly added json_gobject_from_data() correctly uses gssize instead.
* gobject: Uniform JSON<->GObject mapping codeEmmanuele Bassi2009-10-281-28/+54
| | | | | | | | | Rename json_gobject_new() to json_gobject_deserialize(), and json_gobject_dump() to json_gobject_serialize(); this maps the JSON GBoxed API. Also for consistency, change the serialize() return value and the deserialize() argument to be JsonNodes of type JSON_NODE_OBJECT.
* build: Split out GBoxed and SerializableEmmanuele Bassi2009-10-271-367/+4
| | | | | | The json-gobject.c is getting pretty crowded; we should split out the JsonBoxed API and the JsonSerialized implementation into their separate source files.
* gobject: Make GObject<->JsonObject functions publicEmmanuele Bassi2009-10-271-2/+28
| | | | | The functions mapping a GObject to and from a JsonObject should be public, as they can be used by parsers.
* gobject: Reuse the list dataEmmanuele Bassi2009-10-271-1/+1
| | | | | | | | | | | Since we ignore all members that don't have a corresponding GParamSpec for the class we cannot use: members = g_list_prepend (members, pspec->name); Because pspec might also be NULL. We can reuse the GList iterator data field, since that points to data internal to the JsonObject we are iterating over.
* gobject: Add experimental GBoxed<->JSON transformationEmmanuele Bassi2009-10-271-2/+262
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Serializing and deserializing GBoxed types is fairly complicated currently. If a GObject implements JsonSerializable it is possible for the class to intercept the JsonNode, parse it manually and then set the value to the property. This leaves a hole opened for: • manual (de)serialization of GBoxed types • (de)serialization of GBoxed properties in classes not implementing JsonSerializable In order to serialize and deserialize a GBoxed JSON-GLib should provide a mechanism similar to the GValue transformation functions: when registering the boxed type the developer should also be able to register a serialization and a deserialization functions pair matching the tuple: (GBoxed type, JSON type) The serialization function would be: JsonNode *(* JsonBoxedSerializeFunc) (gconstpointer boxed); And, conversely, the deserialization function would be: gpointer (* JsonBoxedDeserializeFunc) (JsonNode *node); Obviously, the whole machinery works only for GBoxed types that register the serialization and deserialization functions.
* Remove a stray ';' that broke deserializing GStrvEmmanuele Bassi2009-10-271-1/+1
| | | | | The stray semicolon was preventing the GPtrArray from being updated.
* Fix compiler warnings (remove unused variables)Emmanuele Bassi2009-10-271-2/+1
|
* gobject: Support constructor propertiesEmmanuele Bassi2009-10-271-11/+87
| | | | | | | | | | | | The GObject deserialization code currently skips all the constructor and constructor-only properties. In order to implement them we can add a preliminary pass on the JSON object members and build a GParameter array. As we don't have a GObject instance we cannot really use the Serializable interface to provide custom parsing for complex data structures, thus we fall back to the default deserialization code path.
* gobject: Serialize properties holding a GObjectEmmanuele Bassi2009-10-271-0/+14
| | | | | Like we deserialize them, we can serialize GObject properties defined using GParamSpecObject.
* gobject: Split GObject serialization codeEmmanuele Bassi2009-10-271-52/+61
| | | | | | Like for the deserialization of a GObject into a JsonObject we should split out the serialization of a GObject into a JsonObject part of json_serialize_gobject() into its own private function.
* gobject: Recurse in GParamSpecObject propertiesEmmanuele Bassi2009-10-271-1/+13
| | | | | | | | | | | | | Use the newly added json_gobject_new() internal function to recurse into properties defined using GParamSpecObject. The same rules used by json_construct_gobject() apply to the properties storing a GObject - including JsonSerializable support. The test case for serialization and deserialization of a GObject has been updated to include a property holding a GObject.
View Lorry Controller Status