Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!SHAMASH.MCRCIM.MCGILL.EDU!mouse
From: mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  X11R5 Dreams
Message-ID: <9008302203.AA20951@shamash.McRCIM.McGill.EDU>
Date: 30 Aug 90 22:03:37 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 70

Jonathan Meyer writes a plea for reworking the color library routines.
For the most part I agree with him, but have a couple of comments.

> Whoever named the following two procedures must have been a little
> tired:

> 	XAllocColor      - allocate single READ ONLY color cell
> 	XAllocColorCells - allocate multiple READ WRITE color cells

The names actually do make sense.  In XAllocColor, you are allocating a
color; the fact that it happens to live in a colormap cell is more or
less incidental.  In XAllocColorCells, you are allocating the colormap
cells per se, rather than asking for a color and getting a colormap
cell as a necessary side-effect.

Not that this means I think they couldn't be improved.

> What happened to multiple read-only color cells, or a single read
> write color cell?

Briefly, the former isn't wanted much and the latter is trivial.

In more detail....  Applications that want read-only colors typically
want only a few of them (foreground, background, highlight, perhaps),
so an interface allowing multiple XAllocColor()s to be done at once
would not get much use.  Allocating a lone read-write cell, of course,
is done by allocating multiple read-write cells but passing a count of
one instead of something higher.

Again, this is not to say the situation can't be improved.

> Another thing I miss is the ability to determine whether a pixel
> value is a valid allocated color, an unallocated color, and whether
> it is read-write or read-only for a specific display connection.

I think the philosophy is that you shouldn't care about any colormap
cells (aka pixel values) that you didn't allocate.  Why do you want to
find this out?  You may be trying to solve the wrong problem.

(As for the last part of your sentence, colormap cells are either
read-only or read-write globally, not read-write to some connections
and read-only to others.  The Xlib manual notes that you *can* stomp on
some other program's read-write cell, but that it's of course rather
antisocial behavior.)

> Personally, I'm happy with sun rasterfiles, and support converting
> between pixmaps and rasterfiles would be wonderful!

Until/unless Sun donates the rasterfile format, and routines to use the
things, to the free software community, it seems unlikely (to me) that
X will use them.  In the meantime, there's xpmtoppm and ppmtoxpm[%],
which you can use with ppmtorast and rasttoppm....

Of course, most of the usefulness of Sun rasterfiles is the Sun pixrect
library, not the file format itself.  I'm tempted to write free
replacements for the pixrect library routines - which of course one
wouldn't use on a Sun, because they'd be slower than the originals, but
might be nice to have elsewhere.

The format also needs to be extended to handle depths other than
1/8/24, and probably a few other things...perhaps someday when I'm
feeling bored.

[%] I assume xpmtoppm and ppmtoxpm exist; I haven't picked up the xpm
    software yet....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu