Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!ptimtc!rdmei!icspub!taeko!digigw!rlee From: rlee@digigw.digital.co.jp (Robert Lee) Newsgroups: comp.windows.interviews Subject: Arcs & IV 2.6 Keywords: Arcs, Chord, Pie, Idraw, InterView Message-ID: <725@digigw.digital.co.jp> Date: 9 May 91 05:30:51 GMT Organization: Digital Electronics Corp., Osaka, Japan Lines: 78 Recently, there have been one or two postings regarding arcs (with a possible solution even being posted). We have done some work in adding arcs in the library, and modifying Idraw to draw arcs. However, since I'm working for a company which intends to market the Idraw I am working on, I cannot readily release the source code. However, I've asked my manager to get the company to release the rights to our work so we can release the source. Arcs are only a small part of our work so far. Be warned however: we are using InterViews _2.6_, and we do not know if the modifications are applicable to 3.0. With regards to patches/improvements, I don't know if the company is willing to support it, but it would be really nice if I can give my work to someone so that they can support it. However, that would _really_ be asking alot (i.e. even _I_ would not want to support somebody elses work). Of course, we would try our utmost to release correct code. The second warning is that we modified the library. We also were thinking of creating a second painter class, but vetoed that idea because 1) modification to Idraw would have been to crazy, and 2) this is a "good" thing which other applications may want to take advantage of. What we did was to implement in Idraw, the ability to draw 5 different types of arc: arc, chord, pie, filled chord, and filled pie. There are two steps in implementing arcs in Idraw: 1) modify the library so that it can draw arcs, and 2) modify Idraw so it can draw arcs. 1) Modifying the library. (I worked on this part) There are several steps involved here as well. a) modify the Painter class so that it can draw arcs. Fairly simple. b) modify the Base class (it has some helping functions) to draw the arcs. Again fairly simple. c) create 5 Graphic classes which correspond to Arc, Chord, Pie, Filled-Chord, and Filled-Pie. This was the most time consuming. Also, some of my implementation is not quite correct. With Part c, I looked at the demo program, "graphics", and used it as a driver to test the new classes. I think the hardest part was trying to figure out the semantics of the "methods" which each Graphic class had to provide. Essentially, each of the classes had to implement getExtent -> returns the bounding box. contains -> given a point, is there a "hit" on the shape intersects -> given a box, is there a "hit" on the shape draw -> draw itself. Since I was modifying the library, there was essentially no documentation other the source for other shapes (To the authors of InterViews: THANK YOU VERY MUCH FOR WRITING GREAT CODE. Otherwise, I would never have been able to complete this part). The one part which snagged me was intersects: Given a box, what is the semantics of intersects? i.e. if the box surrounds the shape, does intersects return true? what if the box is totally enclosed in a solid shape? I didn't implement the second part (modifying Idraw), but current implementation has some problems so I may have to take a look into it real soon. I don't think this part is too difficult. Postscript support is not there yet, and I don't know if we ever will put that in. The way it is currently implemented, there are 3 classes: ArcSelection, PieSelection, and ChordSelection. However, if I would have done the implementation, I would have tried to make the chord/pie thing as an attribute of shapes, but that would be more involved. I think there are other parts to it as well, i.e. RubberArcs had to be implemented and such, but that was probably quite simple too. Once I get the okay from management, I'll try to find some time to put together a patch. Robert rlee@digital.co.jp (We ain't DEC, but I've got a friend there)