[gmpi] Re: GUI Look & Feel (OT)
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 16 Apr 2003 05:59:54 -0400 (EDT)
On Tue, 15 Apr 2003, Chris Grigg wrote:
> Getting platform-native L&F is good, but I would also like to hear
> from the commercial plug developers about how important it is from a
> brand identity POV to have the plug-in control its own look & feel,
> i.e. looking the same, or nearly, on all hosts.
It's very important to have it available, but it's also important to be
able to switch it off and allow the user to access the plug reasonably
effectively from system-native widgets.
Different vendors will have different ideas as to the balance of those
two; it's probably rather difficult to build a library that sits
on top of the system-native widgets on whatever platform it is running on
and at the same time provides the level of GUI customization that vendors
will want.
Therefore my suggestion would be to have plugins provide a parameter map
with a rich level of information, and provide a parameter model that
allows the host app to build a usable GUI (though potentially ugly, and
not *as* usable as the custom GUI might be) for almost any conceivable
plugin. That means providing, at the very least, momentary and latching
buttons and file-access controls as well as knobs and faders, and having
the ability for the plug to convey the notion of "parameter grouping" to
the host (thinking here of making a plug with 50+ parameters actually
usable to someone without visual cues). Basically I'm thinking along the
lines of an XML document that relates to the parameter map and can be used
by the host to lay out a default UI with system-native controls. This type
of parameter description document will also be very useful for hosts that
support advanced control surfaces (Mackie Control and the like).
Alongside that, we also provide the hooks for a plug to implement its own
GUI, however it might see fit.. custom bitmaps, OpenGL (if available),
platform specific code.. whatever, it's up to the plugin vendor (within
limits, obviously); this GUI object should be isolated from the plugin's
GMPI DSP code and communicate via a host-mediated pipe.
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
Other related posts:
