[gmpi] GUI Look & Feel (OT)

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 15 Apr 2003 12:41:46 -0700

Going OT to respond to Jim... (Hi, Jim!)

At 2:21 PM -0400 4/15/03, Angus F. Hewlett wrote:
Marc, I agree 100%.
[snip]
On Tue, 15 Apr 2003, Marc Poirier wrote:
[snip] 
 > Well, I think that
 > developers will stop circumventing it if they can't get away with that
 > anymore.  Let's not give up before we even started and pander to
 > developers' laziness.  Let's do things right from the beginning and let
 > the developers start doing things right before they accumulate a
 > collection of legacy code that fails to meet our needs and expectations in
 > the near future.

I think I agree with this sentiment (except that the group is contemplating giving up), but I have some observations from past experiences working with audio developers. (Full disclosure: I'm no engineer.)

Good developers take shortcuts when they:
- cannot accomplish something necessary without breaking the rules
- can't readily understand how to do something properly due to
  inadequate documentation or sheer API complexity
- find it an order of magnitude easier, or quicker, to do something
  the wrong way
- (other obvious things I can't remember at the moment)

I don't find any of those first three things to be essentially "laziness."

The current effort, with a lot of great brains hard at work, has more than enough of a chance to nip those problems in the bud. Rather than putting the finger on lazy developers, there's a chance to make it easier for them to do the right thing. Others with direct experience will probably have to weigh in on whether separating GUI/DSP enables or disables that.

Personally (and perhaps in a slightly desperate attempt to haul this back on topic), I would favor splitting them, if only because I would advocate a system whereby plug-ins are able, but not required, to specify the the types and data bounds of GUI elements required for user control, and let the host display a GUI appropriate for that host's look & feel. (This would probably work best for simpler plug-ins that only require sliders, checkboxes, text fields, etc.)

Cheers,
Jim Rippie

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. (Guess I'm thinking of the Universal Audio UREI front panel grafix, etc.) Yeah, this is marketing and not tech, but I thought I should at least ask the question. Maybe displaying a company & product logo badge bitmap would be enough...?

FWIW, portable native L&F is not always that simple to do; e.g. in Tcl/Tk for Mac OS (pre-X) it turned into a big nightmare that delayed many releases and never worked all that well -- particularly, never looked all that good -- due to differences in native widget sizes, behavior, etc. Whereas we want commercial plug developers to use GMPI, so maybe we should try to make sure the GUI side doesn't do anything to prevent a polished & branded appearance. I have a hunch that it might be considered pretty important, and if it is and we .don't. provide a way to do that, it would tend to discourage GMPI uptake.

        -- Chris Grigg
              Beatnik Inc. (standards) / MMA Tech Board (chair)

----------------------------------------------------------------------
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:

  1. Home
  2. gmpi
  3. Archive
  4. 04-2003