>>>>> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> Dear all, I now finally get a chance to go back to this
Bo> auto-cls-layout patch. Please allow me to reiterate the goal of it
Bo> (r13611).
Bo> 1. When a layout file is stored with the .lyx document, the layout
Bo> file can be automatically recognized and used. This allows me to
Bo> open and edit a lyx document (most likely sent by others) without
Bo> having to put the .layout file to $HOME/.lyx/layouts, .cls to
Bo> localtexmf, texhash and re-configure.
Bo> 2. The .cls file can also be stored with the document, and will be
Bo> used. It can also be in any place that latex knows through
Bo> $TEXINPUTS. A slave document may not be compiled directly if it
Bo> can not access this .cls file (e.g. when it resides in a directory
Bo> different from its master).
These are good goals :)
Bo> This is addressed in the attached patch. OK to apply?
Please wait before applying this patch, if only because there are
stylistic issues:
+ // Read style-file, provided path is searched before the system ones
+ string layout_file = "";
string layout_file;
+ if (path != "")
if (!path.empty())
+ layout_file = path + "/" + name_ + ".layout";
layout_file = addName(path, name_ + ".layout");
+ if (layout_file == "" || !fs::exists(layout_file))
if (!layout_file.empty() || !fs::exists(layout_file))
+ layout_file = libFileSearch("layouts", name_, "layout");
+ loaded_ = const_cast<LyXTextClass*>(this)->read(layout_file) == 0;
- bool load(std::string const & path=".") const;
+ bool load(std::string const & path="") const;
bool load(std::string const & path = std::string())
Bo> This is a non-issue. When the master document is loaded, the
Bo> layout is loaded and is available to the slave documents that will
Bo> be loaded later. As you have mentioned, there is no fix to the
Bo> situation when the slave document is loaded without its master.
This situation is bad in general. Assume for example that you have
dir1/foo.layout
dir1/foo.lyx
If you load foo.lyx, the class foo is available everywhere. Now,
someone can create a file dir2/foo2.lyx using class foo. This file
will not be usable in general.
This kind of situation is the reason why I say the feature is not
ready.
I know this answer will prompt you to produce yet another patch that
copies foo.layout from one directory to the other, but this is not
what I have in mind ;)
JMarc > I think we should stop and think.
Bo> Any idea now?
One idea I had in mind is to load the textclass locally (add a
lyxtextclass member in BufferParams that will be returned by
getLyXTextClass). This means that textclasses should never be accessed
by textclass number but by this function. I know this is not easy to
get right, but this qualifies more in my eyes as a 'clean' solution.
Of course, this would mean that child document would not see the
master class anymore. I wonder in general if we should tweak
Buffer::params() to return the BufferParams of the master document
always. This is quite radical, but it seems to me that it would solve
several problems (including this one) and maybe be better for the end
user (if you change document settings of a child, they are actually
changed in the master). In general we lack a good model for compound
documents.
These are just words of course. I have no code, and I am not sure it
would work. But the concepts make more sense to me.
JMarc
