home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.96 / text2671.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  1.5 KB  |  34 lines
  1. In article <m0uDb9b-000GOKC@gwar.ardi.com> mat@ardi.com (Mat Hostetter) writes:
  2. >   I think the problem is that Executor ties up his colormap, so
  3. >   subsequently run programs can't get the colors they desire.  Since you
  4. >   are running in 16bpp mode, you have no colormap and everything works.
  5. >
  6. >   "-privatecmap" is one workaround for his problem, although not a
  7. >   perfect one.
  8. >
  9. >   -Mat
  10. Mat,
  11.     Your response got me to thinking about the problem of running
  12.     Executor with an 8 bit colormap. The current options leave you
  13.     with two extreme solutions. You can either run in the root
  14.     colormap resulting in Executor eating up many of the available
  15.     256 colors that are then not available for other programs or you
  16.     can use the privatecmap option which then results in
  17.     funky/annoying color changes as you change windows. Perhaps there
  18.     could be a more flexible intermediate option that allows you to
  19.     specify & limit the number of colors that Executor will use for
  20.     itself (I know that this can't happen until post Executor
  21.     2). In a sense such behavior is already possible. Specifically,
  22.     if you run Executor after allocating many of the available
  23.     colors, then Executor manages to run with the remaining available
  24.     colors albeit with a somewhat changed on screen appearance. The
  25.     feature that I am suggesting would simply allow you to specify
  26.     the number of colors that Executor can use and then Executor
  27.     would try to make the best use of them (eg. pick the closest
  28.     available color). Is this a reasonable suggestion?
  29.  
  30. Jeff Kosowsky 
  31.  
  32.  
  33.  
  34.