[LV2] LV2UI_Resize as extension_data

[David Robillard]

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