22 Feb
2011
22 Feb
'11
7:08 p.m.
On Tue, 2011-02-22 at 04:52 +0000, Jeremy Salwen wrote:
[...]
Hi David,
As a plugin developer, I'm very much looking forward to this,
especially since I proposed something similar to this a bit ago
(http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.org/…
:) But the fact that you're capable and willing to implement this solution means a
lot more than my confused half-baked ideas. I look forward to the day when embedding and
cross-toolkitedness walk hand in hand.
Right, what you describe here is more or less what I am getting at (it's
come up several times in the past), except rather than bundling it with
every UI (which is copy-paste code reuse and all sorts of nuisance
waiting to happen), I think it should just be a normal system library
that hosts can use to do the job.
We generally have the philosophy that if there is a choice, complexity
does not belong in the plugin (or UI). Putting the complexity in the
plugin is bad bad bad, plugins should be small and easy to write. In
this case, a plugin UI should just implement and expose its widget -
dealing with that widget is the host's problem.
In this case, we have a tricky enough complexity that we don't want it
duplicated in all the hosts either, so a library is definitely the way
to go. I call it Suil :)
Cheers,
-dr