Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!uunet!pcrat!rick
From: rick@pcrat.uucp (Rick Richardson)
Newsgroups: comp.windows.x
Subject: Re: R5 wish list
Message-ID: <1990Aug9.182758.6240@pcrat.uucp>
Date: 9 Aug 90 18:27:58 GMT
References: <9008031915.AA24235@sae.com> <990005@hpnmdla.HP.COM>
Reply-To: rick@pcrat.UUCP (Rick Richardson)
Organization: PC Research, Inc., Tinton Falls, NJ
Lines: 78


The call for features in R5 has been put out. We're stuck running
R3 here, so based on that I'll put in my two cents.  You'll find
that my opinions stem from a developers creature-comforts standpoint,
rather than trying to invent an earth-shattering-new-feature.

	- Everything we do involves images in some form or another.
	  Anything that speeds up handling of images, or makes it
	  simpler to use them is welcome.

	- Despite the warts and all of TIFF, I think that the
	  fact that it is extensible (which can also be considered
	  a wart) makes it the format of choice.  The availablity
	  and quality of Sam Leffler's PD TIFF library is a
	  compelling reason to choose TIFF as the native image
	  format for X.  A merging of Jef Poskanzer's excellent
	  image processing algorithms from PBM, combined with
	  Sam's TIFF library, and command line/batch language/
	  library call capability to do multiple image processing
	  steps within the same program (avoiding the overhead of
	  pipe communication for large images) would go a long way
	  towards making this a useful standard.

	- I realize there is some discussion concerning bitmaps
	  going on.  In my experience, it is sometimes useful
	  to put an image into bitmap (Pixmap) format.  Unfortunately,
	  as near as I can tell, Pixmap's (unlike XImage's) do not
	  allow image bit/byte ordering to be specified to conform
          to the typical msb-first image representation, so you
	  have to ram an image in msb-first format through a mirroring
	  loop (data[y][x] = mirror[data[y][x]]).

	- It is doubtful that there will ever be a binary standard
	  for Xlib and Xt shared libraries under SVR3.2 or even SVR4
	  in the 386/486 marketplace.  For this reason, software
	  developers will be forced into producing platform specific
	  binaries compiled against shared libraries from each of the
	  'major' UNIX/X11 vendors, plus a non-shared (cover-your-ass)
	  version for the johnny-come-lately UNIX vendors, if they
	  want to reach the widest possible audience.  For this reason,
	  anything that reduces the size of a program using Xlib and
	  Xt will be welcome.  This goes double for Xm, should any
	  OSF people read this.

	- The X resource manager *could* be useful as a generic
	  method for specifying user preferences for *all* UNIX
	  programs (as opposed to environment variables and/or
	  program defined 'config' files).  Some consideration
	  should be made for making it separate and able to stand
	  on its own (perhaps it already can; I haven't tried this).

	- One of the reasons (I suspect) that we are running X3 is
	  that vendors have a significant investment in stablizing
	  the server/library products they sell.  On top of that,
	  I think because Motif required Xt changes in R3, vendors
	  stayed with R3 rather than rock the boat.  I'd like to
	  see R5 released with a stability/confidence level such
	  that vendors will beat a path to its door.  Coordination
	  with the OSF is imperative, and I'm happy to see that
	  this is now occurring.*
	

And now, what you've all been waiting for (drum roll, please):

Obligatory-long-posting-humorous-but-irrelavant-ending-comment:

	One has to wonder, given the acceptance of OSF's Motif,
	and the lack of acceptance of OSF/1, if the OSF should
	be called the Look And Feel Foundation.  And, shouldn't
	UNIX International be renamed to the Foundation for UNIX
	Nurturing?

	That would be FUN and LAFFs.  (Groan)

-Rick

-- 
Rick Richardson - PC Research, Inc., uunet!pcrat!rick, (201) 389-8963