CLIM mail archive

[spr10291] Bug-report: Palette-Full

To: colin@franz.com
Subject: [spr10291] Bug-report: Palette-Full
From: Scott McKay <swm@harlequin.com>
Date: Mon, 21 Feb 94 12:56:47 EST
Cc: cerys@BBN.COM, bugs@franz.com, clim@BBN.COM
In-Reply-To: Colin Meldrum's message of Fri, 18 Feb 94 19:38:34 PST <9402190338.AA15763@vapor.Franz.COM>

   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.