Bo Peng wrote:
Dear all,
3. Use this expandable "unknown" layout for a document without valid layout.
} else {
// a warning will be given for unknown class
- setBaseClass(defaultBaseclass());
+ setBaseClass(unknownBaseclass());
Independently of the local layout problematic I think this last change
goes in the right direction; I never liked LyX to switch automatically
to whatever default layout, resulting in dataloss when the default
layout is article and the document has level one sections for example.
return classname;
}
The result:
1. A document without valid layout will be opened with a warning. (The same)
2. All layouts are usable, although they all look like "standard" (changed)
3. Save such a document will not lose data. The original layout name
will be used. (improved)
4. Another layout can be chosen from Document -> settings, if a
correct textclass is selected, all layouts will work fine. (improved,
because the current approach will change some unknown layouts to
standard.)
I think this is not enough. If the local layout is to be supported,
there should be a way to select this option in the document settings. If
you select this option, LyX should be able to reformat the document
dynamically if a proper local layout is found, or switch to the unknown
layout if not found.
The biggest problem with this patch is that because layout pointers
are used directly, LayoutList, which is std:;vector<Layout> can not be
expanded dynamically. I change it to std::list<Layout> to allow
dynamic growth of the "unknown" textclass but this may lead to
performance problems.
This is wrong IMHO, the vector should stay and you should just construct
this "unknown layout" together with all the others.
Any opinion is welcome.
You have mine. I guess this patch will bring back the debate around the
usefulness of the local layout stuff, I am no expert on this stuff so I
won't comment any further. But please no heated debate; as the 1.6
maintainer, the last decision is on Jûrgen's shoulder and, if he makes
one, it should be respected without any further discussion.
Abdel.
