rgheck wrote:
On 12/31/2009 02:45 PM, Tommaso Cucinotta wrote:
While traveling, I was thinking to a couple of unusual use-cases:
1) create a.lyx and b.lyx
2) let a.lyx include b.lyx
3) let b.lyx include a.lyx
I just tried, and we have segfault after 3) (infinite recursion in
Buffer::masterBuffer() [1]). Probably such operation attempt should
give up with an error to the user (but it may not be easy to identify
an arbitrary "loop" in what is supposed to be a DAG, with documents
that are not necessarily open).
There's an attempt to deal with this kind of problem in other places,
such as InsetInclude. Apparently, it pops up here, too.
There are actually two relationships to deal with: parent ->
children[_positions], and child->[d->]parent.
I tried to fix the infinite recursion in finding master (parent ->
path), but when I add the recursive link, I get infinite recursion in
browsing children (I think it was in updateLabels()).
Create two documents, say a.lyx and b.lyx, and let them *both*
include c.lyx.
Now, open a.lyx, b.lyx and c.lyx.
Who's the master for c.lyx ? I tried through "View->Master", and it
seems the master changes according to the last-loaded master. Also,
when closing one of the two masters, its child is also closed.
This is expected, basically, at least the first part. That the child
closes whichever master closes is wrong.
I noticed the warning about setting the parent to a different one when
already set which Vincent was talking about.
I'm thinking that a user may legitimately want to include the same .lyx
segment in multiple documents, i.e., a .lyx file should be allowed to
have more than 1 master at the same time, or, put in another way,
parent->child it is actually a DAG and non-necessarily a tree.
Basically, from the code perspective, it would seem to me that we would
need:
1) Buffer::getParents(vector<Buffer*> &)
2) replace
Buffer * Buffer::Impl::parent_buffer
with
set<Buffer *> Buffer::Impl::parent_buffers
or
vector<Buffer *> Buffer::Impl::parent_buffers
3) Buffer::getMasters(vector<Buffer*>&)
4) probably keep, for compatibility with existing functionality, a
notion of "first parent" and "first master" which would be found using
just the first element in the parent collection (e.g., View->Master)
But probably consequences on the user interface should be thought about...
T.
