>>>>> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> This is not the supposed way to use a local layout file. The basic Bo> idea of this patch is to make working on an existing lyx document Bo> with foreign layout easier. Agreed. Bo> With a was-coming but stopped second patch, users can create a new Bo> document with such existing local layouts, or can browse for a Bo> layout file in the document->settings dialog. When this file is Bo> saved, if not to the layout directory, we can choose from a Bo> warning, an error, or copying the layout file with the file. I have to admit that a problem I have with these local layout files is that we are going to loose all control over our files. Currently, if there is a bug in article.layout, we can correct it. If we make local versions of these files easy to handle, we are going to see everybody using a file with local versions of article.layout where they added some theorem layout (or they added nothing, but got it from someone who grabbed it from another document) and wondering why it does not work with brand new LyX 1.8. This is the reason why LaTeX people designed the LPPL (where you can make sure that article.cls is really article.cls). In some sense, it might be better have LyX test and say "the textclass 'foo' is not available; do you want me to move foo.layout to ~/.lyx/layouts to make it availble to LyX?". Don't just curse me for that particular proposal, I am just thinking aloud and trying to find what the best modus operandi may be. Bo> (The last one you just laughed at.) It was a bad joke, I admit. >> 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. Bo> I agree. This will make adding layout to lyx easier too. However, Bo> this has nothing to do with the local layout idea. This is where we disagree. You want a particular user feature in, and we try to see how to design it well. The fact that you had some negative feedback on your patch does not mean I do not agree that the goal is a good one. I just means that I do not like the implementation and I am not sure how to do it properly. To me, being able to load textclasses locally is a prerequisite to any local layout patches. You cannot implement local-layout correctly if LyX does not have a notion of local textclass. Bo> You have not said anything specific about local layout files. Bo> Would the mentioned second patch be acceptable? Not before we have a clear idea. I am sorry to look so negative, but this is all I have to offer... On a positive note, I do not have problems with the idea of a local .cls file (which is useful without local layout file). However, it would mix very well with in-LyX checking of files availability (remove the LaTeX checking from configure.py). If calling kpsewhich on each file at start up, we could consider creating a kpsewhich --interactive instance and use that as a server to query files. JMarc
