[gmpi] Re: Requirements
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 15 Nov 2003 09:58:12 -0500
>> I agree with your description. But how you draw a GUI is the hard part.
>> The "here's a window - draw on it" is fundamentally not cross platform.
>
>True. But developers that choose to make chromed UIs should frankly not be
>too worried.
[ ...]
>Personally, I think if we provide a GOOD generic-parameter info mechanism
>(i.e. richer than VST's), we don't have to worry too much about the fact
>that developers that want to make chromed UIs will have to write platform
>specific code.
i don't think its the worry on the part of the plugin developers. its
the host authors who have the concern. i guess i need to restate the
reason why all this stuff is such a problem for us *nix-oids. sorry if
this is repeating stuff that i or others have written before.
the underlying window technology on almost all *nix OS's (OS X being
the only exception i can think of, though there may be others) is X
Window (and 10.3 now supports X Window out of the box, at last!). X
Window is really just a drawing and event protocol, complete with
network transparency built in. Very few people write GUIs using the
lowest layer of X Window - its just too much work and too low
level. so instead, people use toolkits which provide the kinds of
widgets and drawing abstractions that win/macos developers are used
to.
however, each toolkit has its own event handling loop. there is no
"native" event handling loop for X Window, just calls to manipulate
the event queue. the toolkit-provided loop pulls events from the X
Window event queue and processes them (generally by dispatching them
to the relevant widget). this creates a big problem: you can't put two
toolkits in the same address space. they each want to "own" the X
event queue. if they have to share it, bad things happen.
so, its not good enough to say something like "we'll just leave that
to developers later". if plugin GUIs run in the same address space
(i.e process) as the host, then on X Window fronted systems, the GUI
must be written in the same toolkit as the host. this is a SEVERE
limitation. its an almost crippling limitation. there have been hacks
to make specific toolkits cohabit, but they are truly kludgy hacks.
in mitigation, i think some people have told me that the same thing
would happen on windows if you used a different toolkit that did its
own thing with the GDI (??) event queue. but the point is that people
just don't do this - there is one overwhelmingly dominant toolkit and
everything in the audio space uses it.
so, what does this mean? it means that for in-process GUIs, GMPI
either needs to specify the toolkit (which will be very politically
unpopular, and essentially impossible; 80% of the code for ardour is
GUI related, and the chance of me porting it to a different toolkit
than the one i use is zero), OR it needs to provide a toolkit-neutral
way of drawing along the lines of VSTGUI.
the problem is, can you write Halion in VSTGUI ?(Halion being just an
example, but one of my favorites because the HCI aspects of the design
are just amazing)
--p
>> It's not going to be easy, though. Is this how libvstgui works, more or
>> less? We'd require it to be host-provided instead of a generic dll, but...
>
>Yes... libvstgui is a very basic crossplatform graphics library. Note that
>it's linked in to the plugin binary... what you describe is more like a
>host-side graphics toolkit.
>
>
>Regards,
> Angus.
>
>
>----------------------------------------------------------------------
>Generalized Music Plugin Interface (GMPI) public discussion list
>Participation in this list is contingent upon your abiding by the
>following rules: Please stay on topic. You are responsible for your own
>words. Please respect your fellow subscribers. Please do not
>redistribute anyone else's words without their permission.
>
>Archive: //www.freelists.org/archives/gmpi
>Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
>
>
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
