Fwd: Re: C++ explanation please
On 22-Jan-2014 13:39, Johan Engelen wrote:
You have to trace the scope hierarchy manually (e.g. function body -> class declaration -> base class declaration(s))
This is probably a rant...
Never mind tracing the variables, tracing execution to see which parts are actually used can be tedious too. I spent too much of the last day doing just that.
Experimental text decoration display is currently in trunk, along with a patch (in Launchpad) that modifies the Text and Font dialog to allow crude editing of those properties. Now one might think that since Cairo is used for the display, and Cairo is used to render to PDF (and others), that implementing a type of draw for display would automatically show up in render. Nope, none of the text decorations render to a file. As far as I can tell the display and render functions are both intertwined, and separate.
This is what happens when Inkscape saves to a PDF (just the highlights, obviously a lot of other stuff goes on too). Starting at (A)
src/extension/internal/cairo_render_pdf_out.cpp (A) pdf_render_to_document_file() (C) (->B) (H) (->I) (T) DONE!
src/sp_item.cpp (B) invoke_show (->D) (G) (return ->H)
src/libnrtype/Layout-TNG-Output.cpp (D) Layout::show (->E) (F) (return ->G)
(L) showGlyphs (->M) (P) (return ->Q)
src/display/drawing_text.cpp (E) addcomponent (add a glyph to a list, copy some parts of style into _nrstyle) (return ->F)
(Z) _renderItem (draws glyphs for cairo for DISPLAY of text)
src/extension/internal/cairo_renderer.cpp (I) renderItem (->J) (S) (return ->T)
(J) sp_item_invoke_rendering (->K) (R) (return ->S)
(K) sp_text_render (->M) (Q) (return ->R)
src/extension/internal/cairo_render_context.cpp (M) renderGlyphText (->N) (O) (return ->P)
(N) showGlyphs (draws glyphs for cairo for RENDER of text) (->O)
When text is displayed (on the drawing surface) it also follows a call to addcomponent (E) and (if there are changes(?)) Layout::Show (D), but goes through _renderItem (Z) in src/display/drawing_text.cpp, which is never called in the trace above. Text display doesn't touch the rest of the trace shown above. In _renderItem it deals with an object DrawingContext, whereas in the trace above it carries around an object CairoRenderContext. In terms of activity both of these objects are just wrappers around Cairo - but exceedingly different wrappers. _renderItem is fairly similar to renderGlyphText (M) [but ironically, not to renderItem(I)], so renderGlyphText (M) is one logical place to patch in text decorations for render. However, when I implemented text_decoration display, which is called from _renderItem (Z) the code naturally used DrawingContext and _nrstyle (E), and neither of those is available in renderGlyphText (M), which greatly complicates implementing text decoration for render.
Maybe text draw and text render were designed to be this different, but it feels an awful lot like an instance of divergent evolution.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On Wed, 2014-01-22 at 16:37 -0800, mathog wrote:
divergent evolution.
That's apposed to "convergent evolution" (when two things converge in patterns) one would expect the patterns to diverge. But your description sounded more like co/convergent evolution with massive redundant symbiosis. Either way, needs a bit of refactoring.
I noticed a similar pattern in tools-base; I figured I'd leave it alone until it's been re-factored into C++ style classes and then revisit it's relationships later.
Martin,
participants (2)
-
Martin Owens
-
mathog