GSoC - Customizable print formats

Lubomir I. Ivanov neolit123 at
Wed May 6 23:28:44 PDT 2015

On 7 May 2015 at 03:28, Gehad Elrobey <gehadelrobey at> wrote:
> Hello Lubomir,
> I think you have suggested before that I should find a way to remove all the
> existing printing code and replace it with the new Grantlee based printing,
> also you have suggested to use 'NEW_PRINTING' as a preprocessor. So now I am
> not sure if the old printing module will be completely obsoleted or we will
> still keep it as a fallback printing system in the case that someone doesn't
> want to build/install Grantlee.

hello Gehad,
that's a good catch and a bit of a contradiction in a way because i
haven't clarified enough.

my idea was that the temporary macro NEW_PRINTING (of sorts) should be
used while the ongoing work on GSoC is happening.
this means that if a version of Subsurface is released in that same
period, while the new printing module is still WIP, we can simply
disable the NEW_PRINTING macro.
this allows your code to be in master while you work on the project.

this is a complication structure and maintenance wise as we can simply
phase out the old code in a GIT branch (e.g. new-print) without
dealing with the macro, but this way your code should enter master all
at once and the review process will be limited to visitors of your
github page while the work is ongoing.

i pretty much want to make Grantlee a hard dependency i.e. NO_GRANTLEE
means NO_PRINTING, but this raises some community questions:

Dirk and others, what do you think - should we make this new library
dependency (Grantlee) optional like we do with Marble?
Should the printing be completely disabled if the user decides to
build with NO_GRANTLEE or should we fall back to the current Qt-only
based printing (creates bloat as we are going to have 2 printing

also GSoC wise, do you think the new printing code should enter master
while WIP or should it do so all at once when mostly done?


More information about the subsurface mailing list