24 Feb
2011
24 Feb
'11
5:46 p.m.
On Thu, 2011-02-24 at 09:39 +0000, Rui Nuno Capela wrote:
On Thu, 24 Feb 2011 04:19:05 -0500, David Robillard
<d(a)drobilla.net>
wrote:
Check for version >= 0.7.0. You could check that symbol too, I suppose.
Regarding compatibility, I just had a thought: if I made a
slv2_world_set_ui_widget_type or something, and stored that in the
world, then the old function interface could do wrapping without
breaking the instantiation function. Deprecating the old one (w/ GCC
warnings) makes it more obvious to host authors what they need to do,
though... I dunno...
Cheers,
-dr
On Wed, 2011-02-23 at 20:11 +0000, Rui Nuno
Capela wrote:
[snip]
great!
i'll test this stuff asap.
oh, another question on wishing to keep compile-time (#ifdef's:)
retro-compatibility with previous libslv2 releases:
is it correct to assume that "slv2_ui_instance_new" symbol is
determinant to whether we're in presence of this newer libslv2 version?
if not, what would be the correct method, iyo? are you saying that this suil api will get it
implicit and
integrated
into slv2? in a matter of days? i've looked into the "suil.h" and it
makes perfect sense...
I've done this now[1]. The half-baked collection API in Suil as of my
last post was clumsy and out of place. I've removed all that, so Suil
is
exclusively for instantiating (and possibly wrapping) plugin UIs
(deciding which UI to instantiate is the user's problem).
SLV2 now (optionally) depends on Suil. The API changes are minimal;
host
authors just need to switch from the now-deprecated
slv2_ui_instantiate
to its replacement, slv2_ui_instance_new. This new function takes the
same parameters plus an additional widget type parameter which
specifies
the type of widget the host expects. Cross-toolkit embedding should
then
magically work.