On Wed, May 05, 2004 at 09:46:12AM +0200, Georg Baum wrote: > Cengiz Gunay wrote: > > > I believe having a popup which only interrupts an automatic process and > > waits for mouse click/keyboard is not very useful. I would suggest either: > > > > 1) Having a concept of LyX log file/window similar to the LaTeX log > > concept. > > 2) Having little LyX-Warning boxes embedded in the document, similar to > > the TeXError boxes that appear after compilation. > > 3) If you *really* want to keep the popups, then there should be a button > > "ignore all" or a checkbox. Or there should be a way to stop these from > > the preferences. > > I would prefer 1). This would make it trivial to show lyx2lyx messages. > Apart from that, there are other possible solutions for your probblem: > > 4) Just remove this particular popup. Since the document class of the > included document is ignored anyway, the user does not need to know that it > is different. This information is only useful if there are problems because > the included document uses layouts that are not available in the parent > document class, and could only be given in that case. > > 5) Fix the real problem behind: double data definition. Define a new format > for included lyx files that is identical to the normal one but without the > header information (similar to latex). Currently lyx tries to pretend that > files made for inclusion are also usable without the master file. This is very useful, see below.
> This > might work sometimes, but not in general (imagine the case that the master > file has a new command defined in the preamble that is used in the included > document). > Not a problem, see below. > IMHO the cleanest solution is to make it explicit that an included file is > only usable with a master document. > Bad restrictive solution, see below. > I know that this causes problems at other places (e. g. it should be > possible to convert between "normal" and "included" lyx files, what to do > when a user opens an "included" file without a master etc.), so it might > not be good to do it now, but it might be an idea for the future. Seems to me you create a problem without good reason. Now your'e demanding that included file must be of type "subdocument" that cannot exist on its own. Before, the demand was that included files must be the same document class as the master, or it _might_ not work. Either way there is a limit on what can be included, but your way has additional restrictions. Dividing up a large document (or book) in several parts _is_ common. Printing such a part on its own without the master _is_ common too, so this should work! It is not a problem when the subdocument is the same type as the master, because any command defined in the master's preamble is then also defined in the subdocument's preamble, so the result is the same when the subdocument is printed on its own. (A big project naturally gets its own document class. Smaller cases can copy preamples around if need be.) I have a book, where each chapter is a file. Today I can print a single chapter and send it away for review. With your shceme I first have to print the entire book (much slower) to find which pages make up that chapter, then print again selecting only those pages. (Of course this "printing" isn't on paper, I make a pdf). And of course I might even be unable to print the entire book at times, because a co-writer might be busy editing some other chapter making it temporarily broken. Feel free to make a restricted "subdocument" type that may safely be included in any other document class, but don't prevent the current inclusion of same-type documents. Helge Hafting
