Monthly Archives: August 2011
Things are moving on, but they are never as simple as they look on the surface. For example, when changing the properties to store an xmmsv_t value instead of a GTree * containing xmms_config_property_t nodes, I had not realized that the fact that xmms_config_property_t is an xmms_object is very significant, as signals are registered to the objects, and callbacks depend on this. So I’ve had to do a bit of a kludge, but it’s the best I could think of… I added a void pointer to the xmmsv_t structure which holds an xmms_object_t whenever a callback is registered to it. The other issue is that since the xmmsv_t values are always copied on insert, as it would be unsafe to use only references since the tree can be modified in any way, the object pointer will be destroyed when xmmsv_t is released, so I’ve had to manually transfer ownership of the object when necessary. This is really close to working but there are a few bugs and kinks to iron out.
I’ve also started to add the new config schema API to the LADSPA host plugin, by exposing the config API to xform plugins, which has also served to ponder on improvements to the new API, which should be as simple to use as possible. One idea is to use more const references, which will get rid of many xmmsv_unrefs and g_frees which make the new API a big risk for leaks as it’s easy to forget to free that data. This could lead to stale pointers, but it would simplify usage greatly.
IRC chats after this post will probably reveal more thinkgs I hadn’t counted on, but I would think this is what I have left to do:
- Get the callback mechanism working again
- Make sure callbacks work for old and new API
- Implement ideas for callbacks from next section
- Allow nyxmms to set lists (and to handle schemas correctly (e.g. set a n int when the schema is of int type)
- Get the LADSPA host to accept a list of plugins instead of a single plugin.
- Any other lurking bugs or improvements that come up.
Other possible improvements are:
- Use more references for the schema API to simplify its usage
- Mark old API as deprecated so that a compile time warning encourages devs to use the new API
Ideas on how callbacks should work with schema properties
Callbacks can be registered for any node in the config tree, including dicts and lists.
When a callback is set for a certain dict, it should be triggered whenever anything inside it changes, be it a single value change or a new node added or deleted, so when triggering callbacks, all parent nodes need to be checked for callbacks and call them.
Also whenever a large xmmsv_t structure is set (e.g. when you set a number of parameters at once, or even a list of parameters within a dict) all callbacks for the changed items should be triggered.