Re: [LAD] lv2 external UI -- was Re: LV2 Oscilloscope
On 10/11/2013 04:08 PM, Robin Gareus wrote: On 10/11/2013 02:28 AM, Harry van Haaren wrote: On Thu, Oct 10, 2013 at 8:07 PM, Paul Davis p...@linuxaudiosystems.comwrote: If a plugin uses one of them (the original) then Ardour will NOT delete the UI instance when it is closed. If a plugin uses the other (the version forked/copied by falktx) then Ardour WILL delete the UI instance when it is closed. Both specifications state that the UI is defunct and no longer usable after being closed: * After this callback is called, UI is defunct. Host must call * LV2UI_Descriptor::cleanup(). If host wants to make the UI visible * again UI must be reinstantiated. Thanks for clearing that up: learning in progress on my behalf. Cheers, -Harry To clarify this a bit and fill in the details: *All this is only relevant for external UI.* 1) URI: http://kxstudio.sourceforge.net/ns/lv2ext/external-ui correction. the official URI is http://kxstudio.sf.net/ns/lv2ext/external-ui# Ardour3.4 behaves according to spec, see the function documentation of void (*ui_closed)(LV2UI_Controller controller); in the header file http://kxstudio.sourceforge.net/ns/lv2ext/lv2_external_ui.h 2) URI: http://lv2plug.in/ns/extensions/ui#external Ardour 2.X - 3.4 does not follow the spec regarding void (*ui_closed). It just hides the window and shows it again. The reason for Ardour doing (2) differently is that it was agreed on by some developers that for many plugins re-initialization does not make sense (re-init can be CPU intense). Those devs updated the implementation but forgot or neglected to update the spec. AFAIK it's also only Ardour that does not follow the spec. Other LV2 hosts that support lv2plug.in#externalui may implement it as synonym to kxstudio#external-ui. Otherwise the kxstudio#external-ui and lv2plugin#externalui are identical (with just a minor cosmetic difference that kxstudio defines a separate URI for the Host and plugin-widget). In any case, external UI's should be avoided if possible, there are very few valid use-cases. Just use a 'normal' LV2 UI or let the host generate one. ciao, robin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] lv2 external UI -- was Re: LV2 Oscilloscope
On 10/11/2013 03:08 PM, Robin Gareus wrote: In any case, external UI's should be avoided if possible, there are very few valid use-cases. Just use a 'normal' LV2 UI or let the host generate one. I'm sorry, but I have to ask - what is for you a normal LV2 UI? Some might say Gtk2 or Qt4 or X11 on Linux, but things are changing fast that will not allow this. Gtk3 UIs will not work on Gtk2 hosts, with the same regarding Qt4 and Qt5 (and vice-versa). Then don't forget we're moving to Wayland and/or Mir... Current Qt5 release (as of 5.2) doesn't provide a way to embed widgets afaik, like the Qt4's QX11Embed/Container. In my case (of Carla 2.0), I'm moving away from having *any* toolkit code in the backend except native UIs (Linux being X11 for now). This means UIs that use some toolkit (Gtk2/3, Qt4/5, FLTK, etc) and need instance-access will not work. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] lv2 external UI -- was Re: LV2 Oscilloscope
On Fri, Oct 11, 2013 at 10:45 AM, Filipe Coelho fal...@gmail.com wrote: On 10/11/2013 03:08 PM, Robin Gareus wrote: In any case, external UI's should be avoided if possible, there are very few valid use-cases. Just use a 'normal' LV2 UI or let the host generate one. I'm sorry, but I have to ask - what is for you a normal LV2 UI? Some might say Gtk2 or Qt4 or X11 on Linux, but things are changing fast that will not allow this. Gtk3 UIs will not work on Gtk2 hosts, with the same regarding Qt4 and Qt5 (and vice-versa). Then don't forget we're moving to Wayland and/or Mir... Current Qt5 release (as of 5.2) doesn't provide a way to embed widgets afaik, like the Qt4's QX11Embed/Container. In my case (of Carla 2.0), I'm moving away from having *any* toolkit code in the backend except native UIs (Linux being X11 for now). This means UIs that use some toolkit (Gtk2/3, Qt4/5, FLTK, etc) and need instance-access will not work. indeed, the situation is deeply messed up. one conclusion if you care about platform portability is to use GL, but even there, the different implentations of GL even just on Linux can cause significant headaches. PUGL which is a part of drobilla's stack is an attempt to provide a minimal, fully portable subset of GL that a plugin could use on any platform, with any video driver. --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
