CLIM mail archive
Re: [spr10291] Bug-report: Palette-Full
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.
> From: Scott McKay <email@example.com>
> Date: Mon, 21 Feb 94 12:56:47 EST
> Date: Fri, 18 Feb 94 19:38:34 PST
> From: Colin Meldrum <firstname.lastname@example.org>
> 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 email@example.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
> 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
> (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.
Main Index |