CLIM mail archive
[Prev][Next][Index][Thread]

Re: bug in clim:draw-ellipse?


> From root@mbunix.mitre.org 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 <bha%gumby.boeing.com@ada3.ca.boeing.com>
> 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  gmw@mbunix.mitre.org
> 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
> losers.
> 
> 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

> ba
> 
> Brian H. Anderson                     (206) 234-0881
> Boeing Commercial Airplane Co.        bha@gumby.boeing.com
> Seattle, Wa.
> 
> 

0,,
Main Index | Thread Index