CLIM mail archive
Re: bug in clim:draw-ellipse?
> From email@example.com Fri Dec 18 20:56:02 1992
> Posted-From: The MITRE Corporation, Bedford, MA
> Date: Fri, 18 Dec 92 17:31:06 PST
> From: bha <firstname.lastname@example.org>
> Subject: bug in clim:draw-ellipse?
> To: York@lucid.com
> Cc: kanderso@BBN.COM, clim@BBN.COM
> X-Envelope-To: clim@BBN.COM, kanderso@BBN.COM
> X-Mdf: Mail for greg sent to email@example.com
> Content-Length: 2699
> > D) Allow programmer intervention. I had once proposed that back-ends
> > should signal a condition when they encountered an unrenderable case.
> > Application programmers could then establish handlers that could draw
> > alternative graphics, or punt, or whatever. If there is no handler,
> > the back-end can just do B) or C) above. This never got implemented,
> > but do you think it is a good idea? How fine-grained should the
> > condition space be? UNIMPLEMENTABLE-GRAPHIC or a separate condition
> > for each known rendering/ink failure?
> This is what my vote would be for. I believe that CLIM functionality
> should *not* be reduced because some of todays back-ends don't support
> some required feature. Eventually the required functionality will
> come to be, and performance IMHO is not as overriding a concern as
> many would make it out to be. I don't like the lowest common
> denominator approach as it just throws stuff back at the programmer
> who have to implement it anyways because of some box that doesn't
> provide the necessary functionality. We should be striving to provide
> more functionality (CLIM is a *beautiful* system in this regards) to
> make the programmers job easier and delivering good stuff to the end
> I like the idea of providing an escape mechanism for programmers to
> implement their own (necessarily) non-portable extensions. This makes
> things very explicit to the programmer during development (rather than
> doing something that is "close" and maybe confusing the programmer
> unknowningly). This is not to say that some "default" behavior
> shouldn't be provided, but make the programmer explicitly enable it to
> prevent confusion. I'm not qualified to comment on the granularity,
> but it seems that "enough" information must be provided to allow the
> programmer to make a dispatch to the correct routine.
> > E) Documentation. Vendors supplying CLIM back-ends should just be
> > better about documenting which shapes can't be drawn. This puts the
> > burden on the application programmer to study up on all the platforms
> > the application may be delivered into.
> Well, selecting (D) does not preclude (E). Certainly there should be
> documentation on the port. The more the better, and we all know how
> much we like writing this stuff :-)
> BTW - Would CLIM benefit from optional vendor products such as PHIGS
> for the back-end to take advantage of? Maybe the lowest level
> doesn't support everything (you get what you pay for) but if you
> really need more functionality, then buy this niffty vendor add
> on and you have it!
I would like to second this last proposition. I think it is an excellent
notion for leveraging COTS functionality from the C herds. I have heard
several complaints in the past about the lack of support for 3-d graphics
in the CLIM model. I would also think that the advent of display post-script
would usher in some real improvements along the lines of transformable
fonts. -- GMW
> Brian H. Anderson (206) 234-0881
> Boeing Commercial Airplane Co. firstname.lastname@example.org
> Seattle, Wa.
Main Index |