There is no real use for groups in our API. Just use the name of
the file as the default group and be done with it...
Storing multiple groups with this API is problematic because it
forces flushing the file to disk multiple times, one for each group,
and it's just more performant if we use a prefix in the keys
to implement some form of logical separation.
This commit also makes the GKeyFile a temporary object. As we
always load the file from the file system in _load()
and we always replace its contents with a new dictionary in _save(),
there is no point in keeping the keyfile's internal data structures
stored in memory.
Save errors are now also propagated to adhere to the programming
practices of GObject
We have ended up not using them, so let's not carry them
in the ABI of 0.4
We can always revert that, but let's first decide how
these objects should be used
Plugin() is confusing because it's not a constructor, it just finds
an existing instance of a plugin object. All other camel-case
functions are constructors in the current lua API.
This is no longer used and likely not very useful now that we have
a simpler design.
We can re-add it in the future if necessary, but let's keep it out
of the 0.4 release.
Also rename the intermediate lua api table WpDebug -> WpLog
Keeps things more consistent with the function names (wp_log*),
with the lua api (Log.*) and with pipewire using log.{h,c} as well.
After all, these functions are for logging...
This function loads and enables "api" plugins and makes them
available in the specified callback. This is intended to be used
by interactive scripts in order to get access to "api" plugins
such as the new "default-nodes-api" and "mixer-api"
This adds WP_SESSION_ITEM_FEATURE_ACTIVE and WP_SESSION_ITEM_FEATURE_EXPORTED
features, so _activate and _export APIs have been removed. Modules and unit
tests have also been updated.
now that interest is declared on G_TYPE_OBJECT by default
(in optional Interest function arguments), this conditional default
no longer works as expected...
besides, it may be confusing to have a different default depending
on the interest type
it makes no sense to specify the type when calling, for instance,
session:lookup_endpoint() or similar functions
it also makes it easier to use iterate or lookup in the object
manager, when we already know the type of the objects that the om
contains
Add the ability to construct an Interest argument without
using the Interest keyword, so instead of:
om:lookup(Interest { type = "session" })
we can now write:
om:lookup { type = "session" }
... and also remove lookup_filtered from ObjectManager
When an Array or Choice that contains Spa:Id appears as a value for an object
field, it is possible to retrieve the Id type from that object field type.
