mantaraya36's blog

Brain dump

Pencils down notes

Work status

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.

What’s left

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:

  1. Get the callback mechanism working again
    1. Make sure callbacks work for old and new API
    2. Implement ideas for callbacks from next section
  2. Allow nyxmms to set lists (and to handle schemas correctly (e.g. set a n int when the schema is of int type)
  3. Get the LADSPA host to accept a list of plugins instead of a single plugin.
  4. Any other lurking bugs or improvements that come up.

Other possible improvements are:

  1. Use more references for the schema API to simplify its usage
  2. 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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: