CLIM mail archive
Re: [spr10291] Bug-report: Palette-Full

To: swm@harlequin.com
Subject: Re: [spr10291] Bug-report: Palette-Full
From: Kenneth Forbus <forbus@aristotle.ils.nwu.edu>
Date: Mon, 21 Feb 94 13:07:04 CST
Cc: colin@franz.com, cerys@BBN.COM, bugs@franz.com, clim@BBN.COM
In-Reply-To: Scott McKay's message of Mon, 21 Feb 94 12:56:47 EST <12392.9402211756@tigris.harlequin.com>
Just to add my $0.02: This [running out of colors] happens to us all
the time on RS/6000's under Lucid Common Lisp and CLIM 1.1, and it's a
real pain.  I would dearly love a default of the system finding the
closest color it can, with closest being specified on a port-specific
basis and overridable by a user-supplied table.

	Ken

> From: Scott McKay <swm@harlequin.com>
> Date: Mon, 21 Feb 94 12:56:47 EST
> 
>    Date: Fri, 18 Feb 94 19:38:34 PST
>    From: Colin Meldrum <colin@franz.com>
>    Class: bh
>    Bh-Id: spr10291
>    Bh: append spr10291 expire
> 
>    Your problem report has been assigned a tracking id of spr10291.
>    Please use this id in the subject line of any mail related to
>    it so that we may better track communication on your inquiry.
>    Also, please address mail to bugs@franz.com as well as me,
>    so your questions can be answered if I am unavailable.
> 
>      From: Daniel Cerys <cerys@BBN.COM>
>      Date: Tue, 15 Feb 94 13:26:35 EST
> 
>      [Allegro 4.2 - CLIM 2.0]
> 
>      [Franz] CLIM has a very ungraceful method of informing the user that there
>      are no more colors in the colormap to be allocated (signalling this error).
>      In cases where an exact color match can't be found and there aren't any
>      colors to be allocated, CLIM should instead (by default) find the closest
>      match among the shared color cells of the X display and use that instead.
> 
>      Some developers may wish an error to be signalled in this case, but I
>      expect that the majority would prefer the closest-match alternative to be
>      the default behavior.
> 
>    I disagree. I think that in this situation the application it is up to
>    the application to decide how best to deal with situation. Different
>    applications would want to behave differently. For example if you
>    start up an xterm with an unallocated background color when the X
>    colormap is full it uses white (and black for fg) rather than the
>    nearest color.
> 
>    The idea behind the palette-full condition is so that applications can
>    set up their own handlers and take the most appropriate action. The
>    problem is that if your error handler does want to find and use a
>    closely matching color, it is stuck because there are no restarts
>    available and it's too late to change say an :ink option because
>    you're deep down in low level code.
> 
>    I think that providing a restart like use-alternative-color which
>    does the obvious thing would solve the first problem (and perhaps even
>    provide a restart called use-nearest-color). I've filed rfe's to have
>    these considered for a future release.
> 
> I think that such restarts would be quite useful.  It might suffice to
> provide a FIND-CLOSEST-COLOR g-f that takes two args, a palette and a
> color.  Then people can write there own restarts.
> 
>    In terms of the problem with the error happening to late. You can
>    always force the colors to be allocated before any drawing occurs
>    with:
> 
>    add-colors-to-palette palette &rest colors
> 
>      Alternatively (and this should NOT be the default), a developer may wish to
>      allocate a completely separate X colormap for the CLIM application.  Again,
>      this shouldn't be the default.
> 
>    In Allegro CLIM this can be done with something like
> 
>    (make-application-frame 'test
>      :frame-manager
>      (let ((port (find-port)))
>        (find-frame-manager :port port :palette (make-palette port))))
> 
>    This is not the default.
> 
> Just in case it's not clear, the important bit in the fragment above
> is the creation of the new "colormap" via MAKE-PALETTE.
> 

>