>> 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. > > I think it's possible to remove the stack and get the same behavior > another way, like you suggest. I think I cornered myself into > implementing the stack due to the way I implemented color inheritance, > and couldn't think of a cleverer way to do it at the time. You're > asking me to recall the reason for something I coded probably 15 years > ago, as it's part of the core drawing routine. I can't really remember > very well, that far back. I have good reasons for everything I code, > but the code gets worked over so much that often the reason disappears > entirely but the method is still hanging around because I haven't noticed > that it's sticking out like pilings without a pier.
Understood. The nice thing is that you don't have to do much about my rants other than an occasional explanation ;) >> 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. > > Yes, but I prefer PS to PDF because it's a text format and I can read > it and edit it like source code. I consider is simple enough to run > ps2pdf on the result. I'd use PDF as a native format if I could get > pdf2ps to return the original, but it's non-reversible. There's the > additional problem with native PS that the only way to represent one > graphic image multiple times is to make use of virtual memory, and I > have found that this breaks on a number of (most?) printers. Converting > to PDF removes the virtual memory access (apparently by duplicating the > image and placing it in-line where it's called---you can get PDF files > that are larger than the original PS this way), but that's another > irreversible action. In other words, I'm not fixated on PS, but it has > been a good platform for experimenting with new extensions to xcircuit, > since I can first code them by hand directly into PS and see how they > turn out on the printed (or rendered) page. I'm not saying to abandon limited PS as the file format, it's easy enough to deal with. But we definitely need a way to natively print without having the user go manually through postscript. This depends on the drawing system being not hooked up to current editing context. Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
