Bo Peng wrote:
I do not really understand why you need to create several unknown
layouts. Each textclass should have its own.
Currently, I extend a standard textclass such as article when it is
applied to another document. This extended layout list is then
available when a standard article is created. The problem here is that
I do not track which document these 'unknown' layouts belongs to.
I think maybe you're extending the wrong thing, then. The extended
layouts should go into the DocumentClass object associated with the
Buffer, rather than into the LayoutFile object. I think that will "just
work".
I've added some comments to TextClass.h to try to clarify some of the
architecture here. Basically, both LayoutFile and DocumentClass are
based upon TextClass. The former represents a *.layout file; this is
used as a basis for constructing DocumentClass objects that are
associated with a given Buffer. These are supposed to be unchanging,
more or less, since they're shared among open Buffers---though they can
be reloaded from disk via LFUN_LAYOUT_RELOAD.
It is the DocumentClass that is document-specific. The DocumentClass is
created by BufferParams::makeDocumentClass, where it (a) copies the
relevant LayoutFile object, (b) adds information from modules, and (c)
adds document-specific layout---held in BufferParams::local_layout and
read from the header of the LyX file. DocumentClass objects are
therefore more "dynamic"---though this is kind of an illusion because
they don't really change. If you add a new module, then the old
DocumentClass object gets discarded and replaced by a new one. (In fact,
the old one is kept in memory, since there might be things in the cut
stack that need it. But it's no longer associated with a Buffer.)
Now, you might think there's a problem here. Suppose we add the unknown
layout information to the DocumentClass. Then we add a new module, and a
new DocumentClass gets created. What happens to the unknown layout
information? Doesn't it get discarded with the old DocumentClass? Yes,
but when the new DocumentClass is created, we call updateLayout(), just
as if we'd changed the underlying layout file, and then the unknown
layout info should be recreated.
This has real advantages. Suppose I have a document with one unknown
layout. But I have a module that has that layout in it, so I load the
module, and then when we do updateLayout(), the new layout from the
module takes effect automagically. Since modules can be modified on the
fly, you could even write the new layout into an existing module and
then reload.
But if it seems worth keeping a list of unknown layouts and not relying
upon updateLayout() here---and that may be a good idea---you could do
that in BufferParams and then, in makeDocumentClass(), add any that
don't now exist. Viz, at the end of that routine:
vector<string>::const_iterator en = unknown_layouts_.end();
vector<string>::const_iterator it = unknown_layouts_.begin();
for (; it != en; it++)
addLayoutIfUnknown(*it);
And then:
bool BufferParams::addLayoutIfUnknown(string lay)
{
if (doc_class_.hasLayout(lay))
return;
if (find(unknown_layouts_.begin(), unknown_layouts_.end(), lay) !=
unknown_layouts_.end())
return;
doc_class_.addUnknownLayout(lay);
unknown_layouts_.push_back(lay);
}
Or something like that.
Richard
