12 Jun
2010
12 Jun
'10
9:16 a.m.
Hi all,
I am thinking about making a custom GUI for the Autotalent LV2 Port, which
would allow the user to select scales easier and perhaps provide some eye
candy ;).
It seems that there is some issue with LV2 GUIs being not cross-platform
because they require GTK. Therefore it seems to make sense to create a GUI
using Qt, so it will work on most imaginable platforms. However, when I
started googling, I found a discussion on the topic by the author of the
Composite sampler, who wanted to do the same thing. It seemed like he was
actually writing a new extension in order for this to work. However, I
couldn't find any further work on that project, and currently the Composite
plugin doesn't have a custom GUI at all.
So my questions are:
Is it possible to create a Qt GUI with the currently designed extensions?
Which extension should I use if so?
Which hosts support which type of external GUI creation? Would it take
additional code to get any Qt GUI running under them?
Is there any reason I should not use an external Qt GUI?
Where should I start with getting an external Qt GUI to run?
Thanks,
Jeremy
12 Jun
12 Jun
10:42 a.m.
Hi,
LV2_external_ui is your friend. It should work.
http://lv2plug.in/docs/index.php?title=ExternalUIExtension
http://nedko.arnaudov.name/soft/lv2fil/trac/browser
8:11 p.m.
On Sat, Jun 12, 2010 at 4:43 AM, Lars Böttcher <lars-boettcher(a)web.de>wrote;wrote:
Hi,
LV2_external_ui is your friend. It should work.
http://lv2plug.in/docs/index.php?title=ExternalUIExtension
http://nedko.arnaudov.name/soft/lv2fil/trac/browser
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Hi,
That looks good, except the following line presents me with a problem: "A
UI MUST specify its class in the RDF data, in this case ui:GtkUI. The class
defines what type the UI is, e.g. what graphics toolkit it uses."
This wouldn't be a problem if ui:QtUI were defined somewhere, but the only
class which is a sub-class of ui:UI is ui:GtkUI. This seems to be the exact
same problem that I mentioned was being discussed here:
http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2010-March/000491.html
That discussion didn't seem to have a resolution, and I could find any
extension or code output as a result of that, except a simple qt to gtk and
gtk to qt embedding demo.
Jeremy
8:21 p.m.
On Sat, 12 Jun 2010, Jeremy wrote:
That looks good, except the following line presents me
with a problem: "A
UI MUST specify its class in the RDF data, in this case ui:GtkUI. The class
defines what type the UI is, e.g. what graphics toolkit it uses."
Hi Jeremy, you're looking for the docs for the /internal/ UI
extension.
I think you were looking for the /external/ UI extension:
http://lv2plug.in/docs/index.php?title=ExternalUIExtension
-gabriel
9:05 p.m.
On Sat, Jun 12, 2010 at 2:21 PM, Gabriel M. Beddingfield <gabrbedd(a)gmail.com>
wrote:
Can you tell me where I might find some documentation on the external UI
extension? When I followed that link, I followed the URI in the header file
to
#define LV2_EXTERNAL_UI_URI "http://lv2plug.in/ns/extensions/ui#external"
If that is the *internal* UI extension, and seperate from the *external* UI
extension, is there some other wiki page about the external UI extension?
Also, what is the difference? I understand the concept of an external UI,
which is a seperate window launched by the plugin host which controls the
plugin inputs, but I don't really understand what an internal UI would be.
Wouldn't that just be the generic GUI generated by the host?
Jeremy
On Sat, 12 Jun 2010, Jeremy wrote:
> That looks good, except the following line presents me with a problem:
"A
> UI MUST specify its class in the RDF data, in this
case ui:GtkUI. The
class
defines what
type the UI is, e.g. what graphics toolkit it uses."
Hi Jeremy, you're looking for the docs for the /internal/ UI extension.
I think you were looking for the /external/ UI extension:
http://lv2plug.in/docs/index.php?title=ExternalUIExtension
-gabriel
9:14 p.m.
On Sat, 12 Jun 2010, Jeremy wrote:
Can you tell me where I might find some documentation
on the external UI
extension? When I followed that link, I followed the URI in the header file
to
#define LV2_EXTERNAL_UI_URI "http://lv2plug.in/ns/extensions/ui#external"
The header is also the documentation, as is the DSSI-like
universal "wrapper" example.
If that is the *internal* UI extension, and seperate
from the *external* UI
extension, is there some other wiki page about the external UI extension?
Also, what is the difference? I understand the concept of an external UI,
which is a seperate window launched by the plugin host which controls the
plugin inputs, but I don't really understand what an internal UI would be.
Wouldn't that just be the generic GUI generated by the host?
The difference:
How does the UI and the plugin communicate?
Internal: Via LV2 Event messages.
External: Via any inter-process communication system
you can figure out... often OSC.
Who does the UI communicate with?
Internal: The LV2 host application.
External: The plugin via the IPC mechanism.
Who does the plugin communicate with?
Internal: The LV2 host application.
External: Both the LV2 host application and
anyone connected to it's IPC channel.
Who is responsible for drawing the GUI components?
Internal: The LV2 host application.
External: An external process is spawned and
is responsible for all I/O.
Hope this helps!
-gabriel
9:39 p.m.
On Sat, Jun 12, 2010 at 3:14 PM, Gabriel M. Beddingfield <gabrbedd(a)gmail.com
wrote:
On Sat, 12 Jun 2010, Jeremy wrote:
Can you tell me where I might find some documentation on the external UI
Thanks, that helps a lot.
Now that I understand things better, I think I realize that using an
internal UI would be more what I want. If there is already a system in
place for communicating basic input controls, I don't see why I should
reinvent it simply to use Qt widgets. However, the fact that I was referred
to using external_ui seems to imply that an internal Qt Gui is not possible.
The fact that ui:GtkGUI exists and ui:QtGUI does not also seems to indicate
so.
This<http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2010-March/000505.html>mailing
list post says "If
you want to write a Qt GUI, make a URI for a Qt UI type, and
implement it just as the Gtk ones do."
Since I can't find any URI for Qt GUIs, does this mean that it hasn't
been made yet? Or have things changed since that post?
Jeremy
extension? When I followed that link, I followed
the URI in the header
file
to
#define LV2_EXTERNAL_UI_URI "http://lv2plug.in/ns/extensions/ui#external"
The header is also the documentation, as is the DSSI-like universal
"wrapper" example.
If that is the *internal* UI extension, and seperate from the *external*
UI
extension, is there some other wiki page about the external UI extension?
Also, what is the difference? I understand the concept of an external UI,
which is a seperate window launched by the plugin host which controls the
plugin inputs, but I don't really understand what an internal UI would be.
Wouldn't that just be the generic GUI generated by the host?
The difference:
How does the UI and the plugin communicate?
Internal: Via LV2 Event messages.
External: Via any inter-process communication system
you can figure out... often OSC.
Who does the UI communicate with?
Internal: The LV2 host application.
External: The plugin via the IPC mechanism.
Who does the plugin communicate with?
Internal: The LV2 host application.
External: Both the LV2 host application and
anyone connected to it's IPC channel.
Who is responsible for drawing the GUI components?
Internal: The LV2 host application.
External: An external process is spawned and
is responsible for all I/O.
Hope this helps!
-gabriel
9:52 p.m.
On Sat, 12 Jun 2010, Jeremy wrote:
internal UI would be more what I want. If there is
already a system in
place for communicating basic input controls, I don't see why I should
reinvent it simply to use Qt widgets. However, the fact that I was referred
to using external_ui seems to imply that an internal Qt Gui is not possible.
The fact that ui:GtkGUI exists and ui:QtGUI does not also seems to indicate
so.
The bottom line is this:
A. If you want to stick with Qt and have minimal hassles
implementing your plugin, go with the external UI.
B. If you really want an internal UI and want to have
minimal hassles implementing your plugin, switch to GTK+ (or
gtkmm) and use the internal extension.
C. If you really want Qt /and/ internal, then be prepared to
pave roads for everyone else. :-)
D. <flamebait>Establish an extention that is analog to
VSTGUI, where the plugins abstractly define their GUI and
the host is responsible for drawing them.</flamebait> If
you go this route, you'll need to talk/argue it out on the
LV2 dev list.
All of these are fully respectible options.
This<http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2010-March/000505.html>mailing
list post says "If
you want to write a Qt GUI, make a URI for a Qt UI type, and
implement it just as the Gtk ones do."
Since I can't find any URI for Qt GUIs, does this mean that it hasn't
been made yet? Or have things changed since that post?
That is correct... no QtUI type. Since Drobilla said that
to me, I have been occupied elsewhere. I fully intend to
make option C work, if at all possible.
Torben came up with some stuff that worked back-and-forth
using XEmbed... but there was one direction that we couldn't
get to work. (I think we couldn't get a GTK widget to take
ownership of the Qt Widget...)
-gabriel
15 Jun
15 Jun
9:49 a.m.
On Sat, Jun 12, 2010 at 3:52 PM, Gabriel M. Beddingfield <gabrbedd(a)gmail.com
wrote:
On Sat, 12 Jun 2010, Jeremy wrote:
internal UI would be more what I want. If there is already a system in
Hi,
So I've written a GUI, and I've gotten a better understanding of how the Qt
framework works. It seems to me that all that would be necessary is for the
host to pass a pointer to a QWidget, which the plugin adds itself to, and
the rest can behave exactly like the ui:GtkUI. If I'm not mistaken, all
that would be necessary it to write a new rdf file.
Jeremy
place for communicating basic input controls, I
don't see why I should
reinvent it simply to use Qt widgets. However, the fact that I was
referred
to using external_ui seems to imply that an internal Qt Gui is not
possible.
The fact that ui:GtkGUI exists and ui:QtGUI does not also seems to
indicate
so.
The bottom line is this:
A. If you want to stick with Qt and have minimal hassles implementing your
plugin, go with the external UI.
B. If you really want an internal UI and want to have minimal hassles
implementing your plugin, switch to GTK+ (or gtkmm) and use the internal
extension.
C. If you really want Qt /and/ internal, then be prepared to pave roads for
everyone else. :-)
D. <flamebait>Establish an extention that is analog to VSTGUI, where the
plugins abstractly define their GUI and the host is responsible for drawing
them.</flamebait> If you go this route, you'll need to talk/argue it out on
the LV2 dev list.
All of these are fully respectible options.
This<
http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2010-March/000505.html
That is correct... no QtUI type. Since Drobilla said that to me, I have
been occupied elsewhere. I fully intend to make option C work, if at all
possible.
Torben came up with some stuff that worked back-and-forth using XEmbed...
but there was one direction that we couldn't get to work. (I think we
couldn't get a GTK widget to take ownership of the Qt Widget...)
-gabriel
mailing
list post says "If
you want to write a Qt GUI, make a URI for a Qt UI type, and
implement it just as the Gtk ones do."
Since I can't find any URI for Qt GUIs, does this mean that it hasn't
been made yet? Or have things changed since that post?
10:16 a.m.
So I've written a GUI, and I've gotten a
better understanding of how the Qt
framework works. It seems to me that all that would be necessary is for the
host to pass a pointer to a QWidget, which the plugin adds itself to, and
the rest can behave exactly like the ui:GtkUI. If I'm not mistaken, all
that would be necessary it to write a new rdf file.
That's the easy part. Now all that is necessary is that _host
developers_ include support for a ui:QtUI extension. That will be
especially difficult is the host is a Gtk app. Welcome to the plugin
UI holy wars. :-)
Also your plugin outputs MIDI, I don't know how many hosts include
support for that, but I'd reckon not a lot.
At this moment of Linux Audio Plugin History I'd recommend you to
convert your plugin into a standalone application. Then you can add
whatever GUI you want and don't have to worry about connectivity
issues and host compatibility, since all will be handled by
jack/jack-midi/alsa-seq. Add lash or jack-session support and we are
good to go.
HTH,
L
11:03 a.m.
On Tue, Jun 15, 2010 at 12:16 PM, Luis Garrido <
luisgarrido(a)users.sourceforge.net> wrote:
Should work fine with Qtractor at least )))
--
Louigi Verona
http://www.louigiverona.ru/
So I've
written a GUI, and I've gotten a better understanding of how the
Qt
framework works. It seems to me that all that
would be necessary is for
the
host to pass a pointer to a QWidget, which the
plugin adds itself to, and
the rest can behave exactly like the ui:GtkUI. If I'm not mistaken, all
that would be necessary it to write a new rdf file.
That's the easy part. Now all that is necessary is that _host
developers_ include support for a ui:QtUI extension. That will be
especially difficult is the host is a Gtk app. Welcome to the plugin
UI holy wars. :-)
Also your plugin outputs MIDI, I don't know how many hosts include
support for that, but I'd reckon not a lot.
At this moment of Linux Audio Plugin History I'd recommend you to
convert your plugin into a standalone application. Then you can add
whatever GUI you want and don't have to worry about connectivity
issues and host compatibility, since all will be handled by
jack/jack-midi/alsa-seq. Add lash or jack-session support and we are
good to go.
HTH,
L
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
12:05 p.m.
On Tue, 15 Jun 2010 13:03:51 +0400, Louigi Verona wrote:
On Tue, Jun 15, 2010 at 12:16 PM, Luis Garrido wrote:
Should work fine with Qtractor at least )))
nope.
qtractor does the lv2 external-ui extension only. this is the only lv2 ui
extension that is framework/toolkit agnostic.
it is my stance that all lv2 plugin authors should make their plugins
independent of the host implementation gui toolkit. the lv2 external-ui
extension delivers this independence. you can either do in-process or
out-of-process (like dssi), and most importantly you can do it on whatever
toolkit you believe sucks less.
nb. lv2ui:gtk plugins will only show on gtk hosts. lv2ui:qt plugins will
only show on qt hosts, if there will ever be one that supports it
specifically. qtractor won't be one of them, sorry.
fwiw, use the lv2 external-ui extension.
stay away from all gtk (qt) lock-in (lock-out) epidemics ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
So
I've written a GUI, and I've gotten a better understanding
of how the Qt framework works. It seems to me that all that
would be necessary is for the host to pass a pointer to a QWidget,
which the plugin adds itself to, and the rest can behave exactly
like the ui:GtkUI. If I'm not mistaken, all that would be necessary
it to write a new rdf file.
That's the easy part. Now all that is necessary is that _host
developers_ include support for a ui:QtUI extension. That will be
especially difficult is the host is a Gtk app. Welcome to the plugin
UI holy wars. :-)
Also your plugin outputs MIDI, I don't know how many hosts include
support for that, but I'd reckon not a lot.
At this moment of Linux Audio Plugin History I'd recommend you to
convert your plugin into a standalone application. Then you can add
whatever GUI you want and don't have to worry about connectivity
issues and host compatibility, since all will be handled by
jack/jack-midi/alsa-seq. Add lash or jack-session support and we are
good to go.
12:21 p.m.
"At this moment of Linux Audio Plugin History I'd recommend you to
convert your plugin into a standalone application. Then you can add
whatever GUI you want and don't have to worry about connectivity
issues and host compatibility, since all will be handled by
jack/jack-midi/alsa-seq. Add lash or jack-session support and we are
good to go."
I would like to comment this paragraph and advice strongly against what is
suggested here.
Standalone application is cool, but I don't think that Linux needs more
standalone applications which you cannot
save into a project, but which you have to reopen, etc. We need more plugins
and I urge all devs to prioritize plugins
over standalone at any time.
To illustrate my point, please read this article:
http://www.louigiverona.ru/?page=projects&s=writings&t=linux&a=…
Please, please consider this seriously. We really need more plugins and less
standalone apps. Any plugin can become a standalone
app with the use of effect racks, be it JACK Rack or LV2 Rack, but not vice
versa.
--
Louigi Verona
http://www.louigiverona.ru/
1:37 p.m.
save into a project, but which you have to reopen,
etc. We need more plugins
I definitely agree with you, we need more plugins. And more hosts. And
sample libraries. And the ultimate plugin standard with cross-toolkit
guis. And a great many things, like peace in the world, care for the
environment, a deep knowledge of the things we advice strongly about,
etc.
But, coming back to the present (for those of you reading this in the
Wayback Machine, this is 2010, greetings from the past!), a standalone
version of a linux audio module with _Qt GUI and MIDI outs_ will work
tomorrow with any host. No plugin rack that I know of will accept such
a plugin.
But don't lose hope, I assure you that once the plugin uber-standard
is in place and there are hosts that support it (I wouldn't hold my
breath, it is a crapload of work and there are many people involved
that have little spare time for their pet projects and very different
motivations other than yours or my needs) it will be rather
straightforward for any developer to pop up a plugin version of
his/her standalone, as long as the application needs are compatible
with the uberplugin specification.
Peace,
L
2:44 p.m.
On Tue, Jun 15, 2010 at 8:30 PM, Luis Garrido <
luisgarrido(a)users.sourceforge.net> wrote:
Will that standalone version be able to have its parameters recorded and
automated from the host, and have its presets saved and recalled with
relative ease of use? If not, then it will not "work" for a significant
number of use cases, and it will therefore be considered "broken".
Automation and session management remain an Achilles heal of
the modularity of linux audio, as Louigi's article rightfully points out.
Maybe that situation works for you, and I may just be a humble user, but
dammit, I really do want Linux Audio to be the best damn audio production
environment it can be.
In other words, it'd be in a lot of peoples' interests if the issue could be
thrashed out a little more before it gets thrown in the "too-hard" basket.
respectfully
michael
save into a
project, but which you have to reopen, etc. We need more
plugins
But, coming back to the present (for those of you reading this in the
Wayback Machine, this is 2010, greetings from the past!), a standalone
version of a linux audio module with _Qt GUI and MIDI outs_ will work
tomorrow with any host. No plugin rack that I know of will accept such
a plugin.
1:35 p.m.
On Tue, 15 Jun 2010, Luis Garrido wrote:
Also your plugin outputs MIDI, I don't know how
many hosts include
support for that, but I'd reckon not a lot.
This is not true. Several LV2 host applications that I know
of will support MIDI just fine. This include Ingen and
zynjacku. I'm sure there's more.
-gabriel
6:39 p.m.
On Tue, Jun 15, 2010 at 4:16 AM, Luis Garrido <
luisgarrido(a)users.sourceforge.net> wrote:
I already essentially have support for a standalone application by users
loading it in ingen.
The way I see it, if I create a plugin, ingen automatically gives me a
standalone application. If I create a standalone application, I don't
automatically get a plugin.
Jeremy
So I've
written a GUI, and I've gotten a better understanding of how the
Qt
framework works. It seems to me that all that
would be necessary is for
the
host to pass a pointer to a QWidget, which the
plugin adds itself to, and
the rest can behave exactly like the ui:GtkUI. If I'm not mistaken, all
that would be necessary it to write a new rdf file.
That's the easy part. Now all that is necessary is that _host
developers_ include support for a ui:QtUI extension. That will be
especially difficult is the host is a Gtk app. Welcome to the plugin
UI holy wars. :-)
Also your plugin outputs MIDI, I don't know how many hosts include
support for that, but I'd reckon not a lot.
At this moment of Linux Audio Plugin History I'd recommend you to
convert your plugin into a standalone application. Then you can add
whatever GUI you want and don't have to worry about connectivity
issues and host compatibility, since all will be handled by
jack/jack-midi/alsa-seq. Add lash or jack-session support and we are
good to go.
HTH,
L
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
1:34 p.m.
On Tue, Jun 15, 2010 at 3:49 AM, Jeremy <jeremybubs(a)gmail.com> wrote:
Hi,
So I've written a GUI, and I've gotten a better understanding of how the Qt
framework works. It seems to me that all that would be necessary is for the
host to pass a pointer to a QWidget, which the plugin adds itself to, and
the rest can behave exactly like the ui:GtkUI. If I'm not mistaken, all
that would be necessary it to write a new rdf file.
far from true. That would be enough to make the GUI work in a Qt host.
But the problems of making it work in a GTK host, or vice versa,
making a plugin using ui:QtUI work in a Qt host, would remain.
torben, dave and i had some detailed discussions on IRC recently about
some new ideas on how to make this work, but i don't think its easy
and its not likely to appear any time soon.
nothing like the plethora of choices implied by open source
development to royally screw up basic things.
6:30 p.m.
On Tue, Jun 15, 2010 at 7:34 AM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Tue, Jun 15, 2010 at 3:49 AM, Jeremy
<jeremybubs(a)gmail.com> wrote:
How about this idea? The plugin is responsible for creating its own window
if the host doesn't know how to do it.
So for example 1, a Qt application looks at the rdf and sees it is a Qt GUI.
It opens up a new internal frame, and calls the plugins intantiation
function.
example 2, a Gtk application looks at the rdf file and sees it is a Qt GUI.
It calls the plugin's "createWindow" method, which creates a standalone
window to host the widget, and returns the necessary callbacks. Then the
host calls the plugin's instantiation function with the newly created window
as an argument.
This way I can create a new toolkit and it will work with any existing
(well, after this is implemented) host, but be non-integrated. It also
allows tight integration with hosts in the right circumstances, where it
might be very useful (Qt GUIs in LMMS for example). It would even allow the
qtg or gtq embedding to be easily implemented at a later point and work with
the existing system.
This has all the benefits of an external UI, and all the benefits of an
internal UI (when possible).
Jeremy
Hi,
So I've written a GUI, and I've gotten a better understanding of how the
Qt
framework works. It seems to me that all that
would be necessary is for
the
host to pass a pointer to a QWidget, which the
plugin adds itself to, and
the rest can behave exactly like the ui:GtkUI. If I'm not mistaken, all
that would be necessary it to write a new rdf file.
far from true. That would be enough to make the GUI work in a Qt host.
But the problems of making it work in a GTK host, or vice versa,
making a plugin using ui:QtUI work in a Qt host, would remain.
torben, dave and i had some detailed discussions on IRC recently about
some new ideas on how to make this work, but i don't think its easy
and its not likely to appear any time soon.
nothing like the plethora of choices implied by open source
development to royally screw up basic things.
7:43 p.m.
On Tue, 15 Jun 2010, Jeremy wrote:
I.e. the plugin provides both an internal and external UI,
and the host application picks which one. You can already
do that.
Originally I suggested something like VSTGUI. But then
you're building your own abstrict widget toolkit that has to
be implemented by each host. Yuk. But if you're creating
your own widget toolkit, then why not simply pick one
existing one and go with it?
How about this:
All plugin GUI's are GTK.
Plugin authors only have to deal with 1 API. Host authors,
if not using GTK, only have to figure out how to present GTK
widgets (not {GTK|Qt|FLTK|wxWidgets|Athena}).
I'm a Qt fanboi, but going this route is starting to make a
lot of sense to me.
-gabriel
torben, dave
and i had some detailed discussions on IRC recently about
some new ideas on how to make this work, but i don't think its easy
and its not likely to appear any time soon.
nothing like the plethora of choices implied by open source
development to royally screw up basic things.
How about this idea? The plugin is responsible for creating its own window
if the host doesn't know how to do it.
8:14 p.m.
On Tue, Jun 15, 2010 at 12:30 PM, Jeremy <jeremybubs(a)gmail.com> wrote:
How about this idea? The plugin is responsible for
creating its own window
if the host doesn't know how to do it.
insufficient, and already more or less assumed by any sane API. but
the issue isn't window creation. its event dispatch.
9:50 p.m.
I.e. the plugin provides both an internal and external
UI, and the host
application picks which one. You can already do that.
I was under the impression that external UIs use some form of IPC to
communicate, while internal UIs use callbacks to the host.
On Tue, Jun 15, 2010 at 2:14 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Tue, Jun 15, 2010 at 12:30 PM, Jeremy
<jeremybubs(a)gmail.com> wrote:
Do you mean passing resizing and clicking events and such, or like updates
to the input controls?
Jeremy
How about this idea? The plugin is responsible
for creating its own
window
if the host doesn't know how to do it.
insufficient, and already more or less assumed by any sane API. but
the issue isn't window creation. its event dispatch.
9:59 p.m.
On Tue, 15 Jun 2010, Jeremy wrote:
Yes.
Otherwise, every host has to have a Qt-external-window
setup, an FLTK-external-window setup, a GTK-external-window
setup, etc. Kind of defeats the purpose of having the
external UI, doesn't it?
-gabriel
I.e. the
plugin provides both an internal and external UI, and the host
application picks
which one. You can already do that.
I was under the impression that external UIs use some form of IPC to
communicate, while internal UIs use callbacks to the host.
10:35 p.m.
On Tue, Jun 15, 2010 at 3:59 PM, Gabriel M. Beddingfield <gabrbedd(a)gmail.com
wrote:
On Tue, 15 Jun 2010, Jeremy wrote:
I.e. the plugin provides both an internal and external UI, and the host
application picks which one. You can already do that.
I was under the impression that external UIs use some form of IPC to
communicate, while internal UIs use callbacks to the host.
Yes.
Otherwise, every host has to have a Qt-external-window setup, an
FLTK-external-window setup, a GTK-external-window
setup, etc. Kind of defeats the purpose of having the external UI, doesn't
it?
-gabriel
wait, isn't the
LV2UI_Descriptor->port_event() and LV2UI_Write_Function() interface toolkit
agnostic? Wouldn't it be possible to have toolkit agnostic host-facilitated
communication?
Jeremy
10:48 p.m.
On Tue, 15 Jun 2010, Jeremy wrote:
Yes, these are. And these allow plugins to communicate
with other plugins.
However, these functions are executed in the host
application's memory space. So, I don't see how it would
help in having FLTK widgets hosted by a Qt application.
-gabriel
Otherwise,
every host has to have a Qt-external-window setup, an
FLTK-external-window setup, a GTK-external-window
setup, etc. Kind of defeats the purpose of having the external UI, doesn't
it?
wait, isn't the
LV2UI_Descriptor->port_event() and LV2UI_Write_Function() interface toolkit
agnostic? Wouldn't it be possible to have toolkit agnostic host-facilitated
communication?
16 Jun
16 Jun
12:11 a.m.
On Tue, Jun 15, 2010 at 4:48 PM, Gabriel M. Beddingfield <gabrbedd(a)gmail.com
wrote:
On Tue, 15 Jun 2010, Jeremy wrote:
Otherwise, every host has to have a Qt-external-window setup, an
Yes, these are. And these allow plugins to communicate with other plugins.
However, these functions are executed in the host application's memory
space. So, I don't see how it would help in having FLTK widgets hosted by a
Qt application.
-gabriel
I'm not suggesting hosting individual widgets within a foriegn API's frame.
I'm simply saying that it might be possible to abstract the plugin gui
architecture into three parts.
1. The host, which can directly embed a widget if it is of the right type.
2. The translation layer, which can launch a new window to embed the widget
if its toolkit does not work with the host. The host will still have
generic "main event loop" callbacks to the translation layer, which is
provided by the plugin.
3. The widget, which doesn't have to be aware of how it is hosted, but
simply is given a parent widget to add itself to.
Now, this would mean that you could have "external" type windows in the case
where internal windows aren't going to work, and still retain the
"internal"
type process unification, and communication unification. It would also
allow plugin writers to write a *single* GUI implementation which could
function as both an embedded and external widget, with a *single* method for
communication. The "translation layer" would only have to be written once
for each toolkit, and then bundled with the plugins that use it.
Obviously, if as Paul says there are issues handling events, then this might
not work out at all.
FLTK-external-window setup, a GTK-external-window
setup, etc. Kind of defeats the purpose of having the external UI,
doesn't
it?
wait, isn't the
LV2UI_Descriptor->port_event() and LV2UI_Write_Function()
interface
toolkit
agnostic? Wouldn't it be possible to have toolkit agnostic
host-facilitated
communication?
12 Jun
12 Jun
2:41 p.m.
On Sat, Jun 12, 2010 at 3:15 AM, Jeremy <jeremybubs(a)gmail.com> wrote:
Hi all,
I am thinking about making a custom GUI for the Autotalent LV2 Port, which
would allow the user to select scales easier and perhaps provide some eye
candy ;).
It seems that there is some issue with LV2 GUIs being not cross-platform
because they require GTK. Therefore it seems to make sense to create a GUI
using Qt, so it will work on most imaginable platforms.
there are plenty of good reasons to want to choose Qt for this
purpose, but cross-platform is not one of them. GTK runs on all the
same platforms that Qt does.
--p
7:44 p.m.
On Sat, Jun 12, 2010 at 8:41 AM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Sat, Jun 12, 2010 at 3:15 AM, Jeremy
<jeremybubs(a)gmail.com> wrote:
I was under the impression that using GTK would require a user to install
the GTK platform first before it would work, whereas the typical use of Qt
does not require this.
Is this incorrect?
Jeremy
Hi all,
I am thinking about making a custom GUI for the Autotalent LV2 Port,
which
would allow the user to select scales easier and
perhaps provide some eye
candy ;).
It seems that there is some issue with LV2 GUIs being not cross-platform
because they require GTK. Therefore it seems to make sense to create a
GUI
using Qt, so it will work on most imaginable
platforms.
there are plenty of good reasons to want to choose Qt for this
purpose, but cross-platform is not one of them. GTK runs on all the
same platforms that Qt does.
--p
5328
days inactive
5331
days old
linux-audio-dev@lists.linuxaudio.org
28 comments
8 participants
participants (8)
-
Gabriel M. Beddingfield -
Jeremy -
Lars Böttcher -
Louigi Verona -
Luis Garrido -
michael noble -
Paul Davis -
Rui Nuno Capela