On 28-Feb-2014 14:32, Jon Cruz wrote:
On Jan 23, 2014, at 4:34 PM, mathog wrote:
Inkscape::DrawingContext::Save save(dc);
Inkscape::DrawingContext::ContextSaver saver(dc);
Yes, that is less confusing than the original.
That said, the construct is maintenance programmer hostile, since it is hiding something important for not much in return. This appears to be OOP anathema, because the second action must be explicitly coded, but for me the code would be much clearer it it just did the explicit:
cairo_save(ct); ... cairo_restore(ct);
I understand (now) what Inkscape::DrawingContext::Save does, but it took some time to figure it out. Conversely, the cairo save/restore pair is fundamental, and that pair is commonly used in many other places in Inkscape (and hundreds of other programs). If it must be done with the existing methodology, the construct should say clearly what it does:
Inkscape::DrawingContext::CairoContextSaver saved_cairo_context(dc);
Unfortunately this section of Inkscape writes to Cairo for the screen (DrawingContext) in a way that is incompatible with the way it writes to Cairo for file output (CairoRenderContext). These classes aren't derived from each other in any simple way, so reusing the text decoration bits is nontrivial. In fact, the whole text rendering pipeline is sort of, half way, sideways, quasi- replicated in the two cases. Perhaps it's just me, but it seems awfully ironic when the purpose of OOP is to encourage code reuse, that what we have here is a case where wrapping the underlying library (Cairo) in two different and incompatible classes, has discouraged code reuse for the most basic of purposes - writing text!
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech