Georg Baum wrote:
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I understand but I still don't like the scanning... :-)
I don't like it either. But I don't see an alternative yet.
We could just provide the feature if the label is not deeper than
one-level. If the user wants to deeply bury the label inside nested
insets, then he will miss the feature.
Not good. There is no logical reason why it should not work with a deeply
nested caption. Even if you can't imagine reasons to nest captions, there
might be some cases where this is useful.
OK, but it is also possible to do that easily with the tree approach by
creating a recursive helper function using parent().
In other word:
if (parent().lyxCode() == InsetBase::CAPTION_CODE)
name = from_ascii(static_cast<InsetCaption const &>(parent()).type());
if (parent().lyxCode() == InsetBase::OPTARG_CODE
&& parent().parent().lyxCode() == InsetBase::CAPTION_CODE)
name = from_ascii(
static_cast<InsetCaption const &>(parent().parent()).type());
The tree-like approach brings very clean and understandable code IMO.
Except for copy/paste and undo/redo. This becomes ugly.
Well, the copy/paste and undo/redo is ugly at the first place ;-)
But as I said, I don't think the DocIterator and the tree approach have
to be orthogonal. XSL for example allows to scan through and XML using
one of those two paradigm.
Abdel.
PS: I have a patch mostly ready for that.
Why? I fully agree with Andre that the tree<->object decision should be
thoroughly thought out, because it has a lot of implications. This needs to
be done before any coding, and we should not introduce a mixture of both
approaches.
I disagree here.
And if anybody forgot: Now is not the time to make such decisions or even to
discuss them. There are plenty of open bugs and regressions with 1.5.0
target in bugzilla.
OK, let's postpone the discussion to 1.6 then and use the ugly scanning
code for now.
Abdel.
