[LV2] LV2UI_Resize as extension_data

Spencer Jackson ssjackson71 at gmail.com
Mon Aug 25 07:31:11 PDT 2014


 >having two structs with the same functions but for one
>pointer seems silly."
I agree that can lead to spec bloat. Is it outrageous to define that the
LV2UI_Feature_Handle that the host passes in when calling extension data is
actually the LV2UI_Handle? This way the same struct can be used, but the
handle will be different in different contexts.
For what its worth, my plugins don't really need any minimum size. In the
instantiate function I give a default size using LV2UI_Resize as a host
feature, but after that it can be any size the user (or host) wants.


On Sun, Aug 24, 2014 at 7:38 PM, David Robillard <d at drobilla.net> wrote:

> On Fri, 2014-08-22 at 14:49 +0100, Filipe Coelho wrote:
> > On 08/16/2014 05:53 AM, Spencer Jackson wrote:
> > > Hello all:
> > >
> > > I'm trying to implement an FLTK (NTK really) GUI and the only trouble
> > > is that it doesn't resize with the window. I think I finally
> > > understand how its supposed to go:
> > > If the extension data function is called with the uri for
> > > LV2UI__resize then I pass back the LV2UI_Resize struct. The trouble is
> > > the first member is whatever opaque data I wish to use when the
> > > function pointed to by the second member is called. What I really need
> > > when the resize_ui function is called is the instance of the GUI
> > > object created in the instantiate function. So I need to somehow
> > > assign  the LV2UI_Handle to the LV2UI_Feature_Handle. But I don't have
> > > access to it. How is this feature supposed to work as plugin
> > > extension_data?
> >
> > I started to deal with this in my host, I think the UI should ignore the
> > "LV2UI_Feature_Handle handle;" on the Resize struct as it's not possible
> > to have any kind of proper pointer in there.
> > The host will probably pass the UI handle in the resize function, as it
> > is already doing for all other extension-data things.
> >
> > The issue I'm facing now is how to report to the host the minimum size.
> > afaik there isn't a method for this in LV2 yet.
> >
> > Perhaps the LV2UI_Resize struct shouldn't really be used for
> extension-data;
> > I think a new struct would make much more sense, kinda like this:
>
> There are several "bidirectional" feature/extension structs in the UI
> extension like this.  I suppose the correct thing to do needs to be
> documented, but having two structs with the same functions but for one
> pointer seems silly.
>
> (I sometimes wonder if the discrepancy could be eliminated entirely in
> some hypothetical LV3...)
>
> Minimum size and other simple attributes are best done with options,
> unless there's a good reason to have to add new API for it.
>
> --
> dr
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.lv2plug.in
> http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20140825/82196f95/attachment.htm>


More information about the Devel mailing list