UDrawObject takes an optional stack. As far as I can tell, the only use of it is to prevent the following scenario:
1. You've pushed something onto the edit stack (areawin->stack). The edit stack has -- for simplicity -- the original top instance on it. 2. area's expose event draws stuff in the hierarchy *above* our object (areawin->editinplace), this is done in grey 3. as that happens, UDrawObject descends down the stack. Eventually its stack matches the areawin's stack, and that's when it should stop drawing -- otherwise it will draw the currently edited stuff in grey, unnecessarily as it'll later get drawn in proper colors. Is that the only use for stack passed to UDrawObject? If so, UDrawObject can check whether it's above or below current editing hierarchy level, and color things accordingly. I'm also thinking that selected objects should be handled in a similar manner. Right now it seems that drawing code paths are quite scattered, and you can't really pinpoint one place where a given element type's drawing is handled in its entirety. I'm trying to gather it all in a single per-element draw() method that does the right thing, and is passed some sort of a drawing context that includes GC (so that areawin->gc is not implicitly referenced), recursion level, current hierarchy depth, selection list, and such. The use of the drawing context would allow a generic way of painting things while preserving hierarchy -- thus the entire svg module could be removed, and instead the top instance's draw() method would be called with a context that uses Qt's SVG engine for the GC, and has no selections and hierarchy at the top -- this would paint the entire page in spite of what's being done in the UI. Of course the spline/arc strokers would have to be killed first -- we want to export originals, not interpolations, but that's understood. That's my current plan for attacking the drawing. I think that the drawing needs to cleanly decouple the element from the GUI state. Things such as current editing hierarchy or selected objects are parts of the GUI state, and IMHO should be cleanly represented so that element drawing system can be used for both on-screen drawing and hierarchy-preserving export and printing. We do want to support native printing, after all. Note that on anything that's not a Unix, postscript files are by default useless; even on OS X the native printing system uses PDF and to print PS has to be rendered into PDF. Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
