[gmpi] Re: Requirements
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 15 Nov 2003 12:59:52 -0500
>> * provide a toolkit that is implemented on top of
>> existing (popular) toolkits (i.e. host X using toolkit Y would link
>> against the Y version of the GMPI toolkit).
>
>Why not as above, but "Host X using toolkit Y will load the version of the
>plugin linked for Y"?
sure, that's another alternative. but it would lead to paralysis on
*nix systems. of the major sequencer-style apps that exist right now,
ardour is written with gtk, muse and rosegarden are written with qt,
and some others exist that use other toolkits. the likelihood of GMPI
plugins that rely on featureful GUIs being implemented for more than 1
X Window toolkit seems to be close to zero (granted the chance of it
being implemented for even 1 X toolkit is rather small too :).
>> * wait for toolkits to fix this godawful mess.
>
>How soon is that likely to be?
i don't know. the problem is that this is not a problem most programs
face. "plugin" in the *nix world generally refers to things that are
just code, no GUI. there are lots of examples of this. i can't think
of anywhere outside of the audio/midi realm where a plugin is not only
a chunk of code to be executed, but also a GUI. as a result, the
toolkit authors see us as a bizarre niche and don't have much interest
in fixing things.
the sad part of it? it isn't that hard to fix. there are several
approaches, such as providing direct access to an entry point in the
toolkit that just accepts X events that are associated with windows
controlled by the toolkit. another is to remove the insufferably lame
assumption on the part of the toolkits that they own the one and only
connection to the X server.
>> conceptually yes. technically and workwise it would be a real pain. i
>> suspect that most plugins have about a 60:40 to 80:20 split between
>> GUI code and DSP code. the GUI code has to reimplemented for each
>> framework. and if the developer doesn't feel like doing it, it doesn't
>> get done, and their plugins continue to be platform-specific.
>
>That's the developer's own problem at the end of the day. Same as if he
>or she can't be bothered to port it to the Mac. Obviously we should try to
>avoid creating unnecessary platform divisions, but when the platforms
>really are significantly different, what can you do?
vstgui is already an example of what can be done. win and mac GUI APIs
are not at all alike (syntactically anyway), and so its an example of
someone deciding to bridge the gap, reduce developer workload and
enhance end-user satisfaction.
i suspect we can do the same, but i'm not sure yet of the best way to
do this.
----------------------------------------------------------------------
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:
