Re: child document not working as advertised?
On 2009-03-25, rgheck wrote: > Guenter Milde wrote: BTW: Would it be possible to put all hidden buffers in a sub-menu? >> Should I file a bug? > If it's not filed, I guess so. Done: http://bugzilla.lyx.org/show_bug.cgi?id=5872 Günter
Re: child document not working as advertised?
Guenter Milde wrote: On 2009-03-24, Jürgen Spitzmüller wrote: Guenter Milde wrote: Still the master and all brothers and sisters are available in the View menu. BTW: Would it be possible to put all hidden buffers in a sub-menu? Yes. Should I file a bug? If it's not filed, I guess so. Cc me. It's something I've been meaning to deal with. Should be quite easy, actually. rh Günter
Re: child document not working as advertised?
On 2009-03-24, Jürgen Spitzmüller wrote: > Guenter Milde wrote: >> > Still the master and all brothers and sisters are available in the >> > View menu. >> BTW: Would it be possible to put all hidden buffers in a sub-menu? > Yes. Should I file a bug? Günter
Re: child document not working as advertised?
On 2009-03-24, Jürgen Spitzmüller wrote: > Guenter Milde wrote: >> In my view the master/child support will only be complete with a proper >> support of \includeonly > The trickiest task is that you have to make sure that all aux files are > generated once before the document is compiled with \includeonly > including only some children. Proper includeonly support means that LyX > cares about this, i.e., the user shouldn't need to manually compile the > whole thing himself before he can use the feature Yes. The detection should be similar to what LyX already does for bib files etc. and then "generate if needed". > I already spent some time thinking about how this could be done > (technically), but I didn't find a proper solution yet. IMO, a precondition is caching of auxiliary files, so that they are kept across sessions. Therefore I filed bug 5710 http://bugzilla.lyx.org/show_bug.cgi?id=5710 Günter
Re: child document not working as advertised?
Jürgen Spitzmüller wrote: BH wrote: You're right in principle, but in fact it's not given a bug in the implementation of tabs. Let's say I have 3 child documents open in a single window. If I'm in child1 and select buffer-next, I go to child2. But if I'm in child3 and select buffer-next, I expect to cycle around to child1, but instead LyX opens the master document in a new tab in the same window. That should not happen, partly because it makes visible to the user what should be irrelevant. Yes. This is a known bug AFAIR. Right, still lots of things to fine tune in this parent/child feature. The fact is that we need more developers... to address all the issues... But I dare say that LyX is improving with each minor and major releases :-) Abdel.
Re: child document not working as advertised?
Guenter Milde wrote: > In my view the master/child support will only be complete with a proper > support of \includeonly - so that the output will resemble what I see in > LyX (section numbering, cross references, ...) also with compilation of a > single chapter. I could not agree more. Unfortunately, the implementation is not really easy. The trickiest task is that you have to make sure that all aux files are generated once before the document is compiled with \includeonly including only some children. Proper includeonly support means that LyX cares about this, i.e., the user shouldn't need to manually compile the whole thing himself before he can use the feature (this was the case in the old includeonly support we removed some time ago). I already spent some time thinking about how this could be done (technically), but I didn't find a proper solution yet. Jürgen
Re: child document not working as advertised?
On 2009-03-24, Vincent van Ravesteijn - TNW wrote: > Hmm.. I don't really see the major improvement in workflow ;-).. You don't seem to need many cross references between "siblings". Actually, better master/child support was one of the major points I longed for LyX 1.6! As it is a new feature I had to experience some "Kinderkrankheiten" including many crashes and hard to understand/inconsistent behaviour. Still, besides all my criticism I would like to express my thanks for this work. In my view the master/child support will only be complete with a proper support of \includeonly - so that the output will resemble what I see in LyX (section numbering, cross references, ...) also with compilation of a single chapter. Currently, the \include option for child documents is of no use (the only difference beeing a page break (no change if you include a chapter and an error if you include grandchildren in an included doc). Günter
Re: child document not working as advertised?
BH wrote: > You're right in principle, but in fact it's not given a bug in the > implementation of tabs. > > Let's say I have 3 child documents open in a single window. If I'm in > child1 and select buffer-next, I go to child2. But if I'm in child3 > and select buffer-next, I expect to cycle around to child1, but > instead LyX opens the master document in a new tab in the same window. > That should not happen, partly because it makes visible to the user > what should be irrelevant. Yes. This is a known bug AFAIR. Jürgen
Re: child document not working as advertised?
Guenter Milde wrote: > > Still the master and all brothers and > > sisters are available in the View menu. > > BTW: Would it be possible to put all hidden buffers in a sub-menu? Yes. Jürgen
Re: child document not working as advertised?
On 2009-03-24, Abdelrazak Younes wrote: > Still the master and all brothers and > sisters are available in the View menu. BTW: Would it be possible to put all hidden buffers in a sub-menu? Günter
Re: child document not working as advertised?
On 2009-03-24, Jürgen Spitzmüller wrote: > Abdelrazak Younes wrote: >> Well, the master is opened. It is just that it is not _viewed_. > This is irrelevant, from a user POV. Unfortunately not. Opening a child doc takes much more time. Günter
Re: child document not working as advertised?
On Tue, Mar 24, 2009 at 5:45 AM, Jürgen Spitzmüller wrote: > Abdelrazak Younes wrote: >> Well, the master is opened. It is just that it is not _viewed_. > > This is irrelevant, from a user POV. You're right in principle, but in fact it's not given a bug in the implementation of tabs. Let's say I have 3 child documents open in a single window. If I'm in child1 and select buffer-next, I go to child2. But if I'm in child3 and select buffer-next, I expect to cycle around to child1, but instead LyX opens the master document in a new tab in the same window. That should not happen, partly because it makes visible to the user what *should* be irrelevant. Of course, the bug is more general than just this. If I have multiple windows open, each with 2 tabs, when in one window I select buffer-next, I expect to cycle between the tabs *of that window*, but in fact I start getting new tabs opening up in that window of documents already open in other windows. Again, that should not happen. Bennett
Re: child document not working as advertised?
rgheck wrote: > I would myself be happy to see a way of getting that kind of information > into the child even when just compiling it. Otherwise, you have to use > ugly hacks to get your macros into the child in this case. Yoe mean, apart from master-buffer-[view|update]? > I guess what we really need is \includeonly support, as several people have > said. Indeed. But this would be an orthogonal feature. Jürgen
Re: child document not working as advertised?
Vincent van Ravesteijn - TNW wrote: Abdelrazak Younes wrote: This is irrelevant, from a user POV. To most user, yes, you're right. Still the master and all brothers and sisters are available in the View menu. Of course, yes. What I meant is: the user do not have to *bother* about the master, and this really makes a difference when writing multi-part documents. Hmm.. I don't really see the major improvement in workflow ;-).. I use this, too. Say I want to edit chapter two. I open chapter two. All labels are correct. Macros and bibliography information are correct. Etc, etc. Previously, you had to open the master, then open the child from the master. And if you forgot to do this, then none of the preceding would be correct. I would myself be happy to see a way of getting that kind of information into the child even when just compiling it. Otherwise, you have to use ugly hacks to get your macros into the child in this case. I guess what we really need is \includeonly support, as several people have said. Anyhow, the problem I have with the default master setting is that it sets the absolute path in stead of a relative path to my master (this happens when your master is one directory up from your child document, which is often the case, and you use the Browse button to select the master). This means that when you rename the directory where your master and children are in, you have to manually update all children to point to the correct master. This also happens when I open the document from a different location e.g. //pcvanvincent/C/Master.lyx. In this case all children start complaining that they can't find the master: C:/Master.lyx. If it does indeed behave this way, then that should be fixed. There are lots of places already where we calculate a relative path based on an absolute path and then use the relative path. I think graphics does this, e.g. Richard
Re: child document not working as advertised?
Vincent van Ravesteijn - TNW wrote: >Well, I think that if you create your child document, the first thing you > have to do is to add it to the master. So, you have your master already > openend. But this does not solve the problems you described (renaming or moving the master), at least not if this is done outside LyX (e.g., in a file browser). > If you want a bidirectional link between child and master, you should be > able to set this from both the master as the child and in one action. I think we just have different concepts of the whole thing. I think the two directions are not immediately connected. Although a child that has a default master requires this master to include the child (at least in all sensible cases I can imagine), the opposite is not necessarily true. In my opinion, having a "default master" is a property of a specific child, not of the master. That's why it's a child buffer param. Jürgen
RE: child document not working as advertised?
>Jürgen Spitzmüller wrote: >> > What about an option in the InsetInclude that says "set children master" >> > or "this child is only a child of this master", which then >> > automatically sets the master document of its childs. This can be >> > checked and/or set each time the master is opened. When you open a >> > child, it will then automatically find the master. Only in the rare >> > case that you might have a child document which can be included in >> > differen masters, you should uncheck this option ? >> >> I don't like that. Note that the default master is really the default >> master. If you open the child from within another master, that one >> will be assigned. If you first have to uncheck something, then something >> is wrong. >> And I do not think this is a rare case. > >Also, this once again forces me to open the master, which is the very thing >I want to get rid of with the default_master feature. Well, I think that if you create your child document, the first thing you have to do is to add it to the master. So, you have your master already openend. It feels wrong to me to first include the child in the master, then open the child and then specify the master to the child. If you want a bidirectional link between child and master, you should be able to set this from both the master as the child and in one action. >Jürgen Vincent
Re: child document not working as advertised?
Jürgen Spitzmüller wrote: > > What about an option in the InsetInclude that says "set children master" > > or "this child is only a child of this master", which then automatically > > sets the master document of its childs. This can be checked and/or set > > each time the master is opened. When you open a child, it will then > > automatically find the master. Only in the rare case that you might have > > a child document which can be included in differen masters, you should > > uncheck this option ? > > I don't like that. Note that the default master is really the default > master. If you open the child from within another master, that one will be > assigned. If you first have to uncheck something, then something is wrong. > And I do not think this is a rare case. Also, this once again forces me to open the master, which is the very thing I want to get rid of with the default_master feature. Jürgen
Re: child document not working as advertised?
Vincent van Ravesteijn - TNW wrote: Abdelrazak Younes wrote: This is irrelevant, from a user POV. To most user, yes, you're right. Still the master and all brothers and sisters are available in the View menu. Of course, yes. What I meant is: the user do not have to *bother* about the master, and this really makes a difference when writing multi-part documents. Hmm.. I don't really see the major improvement in workflow ;-).. Anyhow, the problem I have with the default master setting is that it sets the absolute path in stead of a relative path to my master (this happens when your master is one directory up from your child document, which is often the case, and you use the Browse button to select the master). This means that when you rename the directory where your master and children are in, you have to manually update all children to point to the correct master. This also happens when I open the document from a different location e.g. //pcvanvincent/C/Master.lyx. In this case all children start complaining that they can't find the master: C:/Master.lyx. What about an option in the InsetInclude that says "set children master" or "this child is only a child of this master", which then automatically sets the master document of its childs. This can be checked and/or set each time the master is opened. When you open a child, it will then automatically find the master. Good idea. Only in the rare case that you might have a child document which can be included in differen masters, you should uncheck this option ? In engineering manuals, this is not a rare case; well, at least it's my own use case ;-) But I don't object that this shouldn't be the default. Abdel.
Re: child document not working as advertised?
Vincent van Ravesteijn - TNW wrote: > Hmm.. I don't really see the major improvement in workflow ;-).. Do you extensively work with multipart documents? For me, this solves one of the most annoying obstacles when working with multipart docs (but of course, no one is forced to use it). > Anyhow, the problem I have with the default master setting is that it sets > the absolute path in stead of a relative path to my master (this happens > when your master is one directory up from your child document, which is > often the case, and you use the Browse button to select the master). This > means that when you rename the directory where your master and children are > in, you have to manually update all children to point to the correct > master. This also happens when I open the document from a different > location e.g. //pcvanvincent/C/Master.lyx. In this case all children start > complaining that they can't find the master: C:/Master.lyx. OK, this might be a problem. But I guess this is fixable. > What about an option in the InsetInclude that says "set children master" or > "this child is only a child of this master", which then automatically sets > the master document of its childs. This can be checked and/or set each time > the master is opened. When you open a child, it will then automatically > find the master. Only in the rare case that you might have a child document > which can be included in differen masters, you should uncheck this option ? I don't like that. Note that the default master is really the _default_ master. If you open the child from within another master, that one will be assigned. If you first have to uncheck something, then something is wrong. And I do not think this is a rare case. Jürgen
RE: child document not working as advertised?
>Abdelrazak Younes wrote: >> > This is irrelevant, from a user POV. >> >> To most user, yes, you're right. Still the master and all brothers and >> sisters are available in the View menu. > >Of course, yes. What I meant is: the user do not have to *bother* >about the master, and this really makes a difference when writing >multi-part documents. Hmm.. I don't really see the major improvement in workflow ;-).. Anyhow, the problem I have with the default master setting is that it sets the absolute path in stead of a relative path to my master (this happens when your master is one directory up from your child document, which is often the case, and you use the Browse button to select the master). This means that when you rename the directory where your master and children are in, you have to manually update all children to point to the correct master. This also happens when I open the document from a different location e.g. //pcvanvincent/C/Master.lyx. In this case all children start complaining that they can't find the master: C:/Master.lyx. What about an option in the InsetInclude that says "set children master" or "this child is only a child of this master", which then automatically sets the master document of its childs. This can be checked and/or set each time the master is opened. When you open a child, it will then automatically find the master. Only in the rare case that you might have a child document which can be included in differen masters, you should uncheck this option ? >Jürgen Vincent
Re: child document not working as advertised?
Hubert Christiaen wrote: > "each has the master of the book as default master". Where do you set this? Document>Settings>Document Class>Select default master document. > I have been looking through all the help files, but I cannot find it. Or > where can I find this in the documentation? * UserGuide, appendix B 1 * EmbeddedObjects, sec. 6.2. Jürgen
Re: child document not working as advertised?
On dinsdag 24 maart 2009, Jürgen Spitzmüller wrote: > I'm currently writing a book. Each chapter is in its own child document, > and each has the master of the book as default_master. Previous to 1.6.0, I > always had to open the master and open the child from there. "each has the master of the book as default master". Where do you set this? I have been looking through all the help files, but I cannot find it. Or where can I find this in the documentation? Sincerely, Hubert -- Hubert Christiaen Bloesemlaan 17 3360 Korbeek-Lo Belgium
Re: child document not working as advertised?
Abdelrazak Younes wrote: > > This is irrelevant, from a user POV. > > To most user, yes, you're right. Still the master and all brothers and > sisters are available in the View menu. Of course, yes. What I meant is: the user do not have to *bother* about the master, and this really makes a difference when writing multi-part documents. Jürgen
Re: child document not working as advertised?
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: Well, the master is opened. It is just that it is not _viewed_. This is irrelevant, from a user POV. To most user, yes, you're right. Still the master and all brothers and sisters are available in the View menu. Abdel.
Re: child document not working as advertised?
Abdelrazak Younes wrote: > Well, the master is opened. It is just that it is not _viewed_. This is irrelevant, from a user POV. Jürgen
Re: child document not working as advertised?
Jürgen Spitzmüller wrote: Jürgen Spitzmüller wrote: Now I just open the chapter I'm working on, and I issue master-buffer-view and master-buffer-update to preview the result. Ah, and remember that this also gives you all master information without opening the master (such as bibliography information, cross references, etc.). Well, the master _is_ opened. It is just that it is not _viewed_. Abdel.
Re: child document not working as advertised?
Jürgen Spitzmüller wrote: > Now I just open the chapter I'm working on, and I issue master-buffer-view > and master-buffer-update to preview the result. Ah, and remember that this also gives you all master information without opening the master (such as bibliography information, cross references, etc.). Jürgen
Re: child document not working as advertised?
Vincent van Ravesteijn - TNW wrote: > >I'm rather surprised how often it is used (given that I mainly > >implemented it for my own needs). So it seems to actually address > >a frequent desire. > > Could you explain when you should use this feature and what it can do for > you ? This is a typical scenario (for me, al least): I'm currently writing a book. Each chapter is in its own child document, and each has the master of the book as default_master. Previous to 1.6.0, I always had to open the master and open the child from there. Now I just open the chapter I'm working on, and I issue master-buffer-view and master-buffer-update to preview the result. This speeds up my workflow a lot. Jürgen
RE: child document not working as advertised?
>I'm rather surprised how often it is used (given that I mainly >implemented it for my own needs). So it seems to actually address >a frequent desire. Could you explain when you should use this feature and what it can do for you ? Beware what you say, because I might start messing up the gui, because even I have no clue how to answer this question. >Jürgen Vincent
Re: child document not working as advertised?
On dinsdag 24 maart 2009, Florin Oprina wrote: > Compiling the entire file takes ages, so I > wanted to split it into smaller chunks. I guess the solution is to just > copy the preamble into each child document. I have a book divided in chapters. I created a copy of the master and add just one chapter as child document to test the layout of that chapter. In this way I can avoid the compilation of the whole book. Sincerely, Hubert -- Hubert Christiaen Bloesemlaan 17 3360 Korbeek-Lo Belgium
Re: child document not working as advertised?
Florin Oprina wrote:
> Thanks. I was under the impression that I don't have to compile the master.
> I thought I can compile only the child document and still get the common
> macros and settings.
No (intentionally not). Because one might *want* to have different settings in
the childs.
> The reason I wanted this is because I have a rather large document and I
> use XeTeX, which is really slow. Compiling the entire file takes ages, so I
> wanted to split it into smaller chunks. I guess the solution is to just
> copy the preamble into each child document.
In this case, I'd suggest to put the preamble's content into a file
"mypreamble.tex" which is saved in the folder of the LyX files, and put
\input{mypreamble.tex} into the preamble of each file (master and childs).
This way, you only need to do changes/additions in one central place.
Jürgen
Re: child document not working as advertised?
Thanks. I was under the impression that I don't have to compile the master. I thought I can compile only the child document and still get the common macros and settings. The reason I wanted this is because I have a rather large document and I use XeTeX, which is _really_ slow. Compiling the entire file takes ages, so I wanted to split it into smaller chunks. I guess the solution is to just copy the preamble into each child document. Best, Florin
Re: child document not working as advertised?
Guenter Milde wrote: > You can compile the master from the child document with the > master-buffer-view and master-buffer-update functions, e.g. > >Esc-x % open minibuffer (command line) > >master-buffer-view pdf2 > > You can also bind these functions to keys if you happen to need them > regularely. For instance, to get it into your toolbar, copy the file stdtoolbars.inc from your LyX System directory to the subfolder "ui" of your LyX user directory (both directories are listed in Help>About LyX, you might need to create the subfolders), and change the "view/update" section as follows: Toolbar "view/update" "View/Update" Item "View DVI" "buffer-view dvi" Item "Update DVI" "buffer-update dvi" Item "View PDF (pdflatex)" "buffer-view pdf2" Item "Update PDF (pdflatex)" "buffer-update pdf2" Item "View Master PDF (pdflatex)" "master-buffer-view pdf2" Item "Update Master PDF (pdflatex)" "master-buffer-update pdf2" Item "View PostScript" "buffer-view ps" Item "Update PostScript" "buffer-update ps" End Then, you need to add two new icons to the subfolder "images" of your LyX user directory (again, you might need to create this folder). Attached are mine (not very nice, but functional). HTH, Jürgen <><>
Re: child document not working as advertised?
Abdelrazak Younes wrote: > This new "master document" feature seems to bring more trouble that it > solved Jürgen ;-) I'm rather surprised how often it is used (given that I mainly implemented it for my own needs). So it seems to actually address a frequent desire. The only thing that is missing is a master-buffer-* gui. Jürgen
Re: child document not working as advertised?
Florin Oprina wrote: Hi all. I use Lyx 1.6.2. I created a child document, selected a default master document and put all my custom commands in the preamble of the master file. In the master file I included the child document. Now, if I compile the child document the settings in the master file seem to be ignored: the custom commands do not work and bibliographic references are not resolved. From the LyX wiki:``Render just a child document and LyX will make sure all macros are defined correctly, even though their real definition is e.g. in the master document.'' But I can't get LyX to work as advertised. What am I doing wrong? Don't forget to include the child document in the master. This new "master document" feature seems to bring more trouble that it solved Jürgen ;-) Abdel.
Re: child document not working as advertised?
On 2009-03-24, Florin Oprina wrote:
> I use Lyx 1.6.2. I created a child document, selected a default master
> document and put all my custom commands in the preamble of the master file.
> In the master file I included the child document.
> Now, if I compile the child document the settings in the master file seem to
> be ignored: the custom commands do not work and bibliographic references are
> not resolved.
Compile the master. Compiling a buffer always uses the preamble and
settings from the local document (even if a default master is set). This
way it is still possible to define local settings for the child document.
(I have my common preamble in an external file and include it in the
master's and child's "Document>Settings LaTeX Preamble" with
\input{preamble.tex}.)
You can compile the master from the child document with the
master-buffer-view and master-buffer-update functions, e.g.
Esc-x % open minibuffer (command line)
master-buffer-view pdf2
You can also bind these functions to keys if you happen to need them
regularely.
Günter
child document not working as advertised?
Hi all. I use Lyx 1.6.2. I created a child document, selected a default master document and put all my custom commands in the preamble of the master file. In the master file I included the child document. Now, if I compile the child document the settings in the master file seem to be ignored: the custom commands do not work and bibliographic references are not resolved. >From the LyX wiki:``Render just a child document and LyX will make sure all macros are defined correctly, even though their real definition is e.g. in the master document.'' But I can't get LyX to work as advertised. What am I doing wrong? Thanks.
