On Sat, 2011-07-30 at 13:03 -0400, David Robillard wrote:
On second thought, this is a poor example. Though the modular heads and
more programmer-user types should get excited, it's a bit nichey. David
being an ontology astronaut again, y'know... :)
A better example of the user visible win of this is menus, which applies
to virtually any host. Following the previous example, the plugin would
describe in its data file that it supports the load filename message.
The details of this message (i.e. what keys it has) are also (ideally)
available to the host.
So, the host knows:
* This plugin supports the load-filename message
* The load-filename message needs one property, filename, with a string
key, for which an appropriate label in my locale is "Filename"
So, it can easily build a context menu and/or dialog box for the plugin
that lets the user load a file without requiring a custom plugin UI to
In other words, a powerful message interface like this doubles as a way
for plugins to provide menu system and/or powerful generic UIs while the
host only has to implement a small core of functionality (i.e. plugins
can add all sorts of messages to mean all sorts of things and since it's
all "dynamic" there is no implementation lag waiting for all the host to
As a sidenote, this deliberately meshes perfectly with our concept of
persistent plugin state, which is also based on a similar dictionary:
Linux-audio-dev mailing list