Yes, I looked at it but didn't have time then to comment.
It's fine as far as it goes, but I was thinking something somewhat different.
Others can chime in, perhaps, but I think there's a reason that OutputParams
was always supposed to be passed as const. At least, it began life as precisely
what it sounds like: A bunch of parameters that give us information about what
we're supposed to output. These, one might imagine, would be set once and for
all when the output routines we launched.
But then, I think, OutputParams grew into a somewhat different beast: A
collection of flags that affect output and that can be set and reset during the
output process. In a way, that's not so difficult: We can copy the OutputParams
to some temporary object, change them as needed, and pass the temporary down
the chain. This gets done quite a lot, in fact. But then it gets worse:
Sometimes, the lower down routines make their own changes, which need to be
propogated *back up* the chain. So now the temporary object solution doesn't
really work.
So, one option, indeed, is to forego the pretense that OutputParams is const
and just pass a reference everywhere. That's what your patch does. The other,
which is what I was trying to do some time ago, is to untangle this mess,
especially the back-propogation of flags from the lower down subroutines.
Making all those things mutable was a hack-ish solution.
A start on fixing this would be to figure out which things really do need to be
back-propogated and which things don't, and make only the former mutable, and
force changes to the latter to be done with a temporary object. Whether it's
all worth doing isn't entirely clear to me.
Riki
Maybe split OutputParams into 2 parts: class with output parameters that
are not changed on document tree traverse (OutputParams, passes always
as const reference) and class with current output state, varied during
traverse (OutputContext, passed always as reference)?
And to implement for OutputContext the push/pop operations (with
internal stack) to save/restore parent context (when needed to do local
changes) or directly modify parent context if changes should be
propagated on the higher level.
Does it make sense?
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
