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