Jean-Marc Lasgouttes wrote:
Helge Hafting <[EMAIL PROTECTED]> writes:
Now, editing the child document may change the whole of it, so
that view->pdf and friends need to recompile and can't use
cached dvi files and such.  A cross reference to something
in the subdocument might change, perhaps. That is fine.
But the master lyx file doesn't change, no matter what I do to the
input'ed file. So it does not need saving, and LyX does not
need to ask me about saving it when I quit.

The problem is not really about loading child document. What happens is
that before doind this 'edit' thing, the code in GuIInclude.cpp does a
applyView, as if you had clicked on OK. The inset then gets modified to
the calue it already had, and this marks the document as (changed).

Bug, but not a regression, lyx 1.5 has the same problem with child documents. Either version is fine with write-protected master
documents, does do not become "changed".

Well, how about calling "applyview" only if something actually changed
in the dialog? I.e. only if the OK-button is enabled. (It is grayed
out as long as there is no change - and gets enabled as soon as
you change something.)

A weird problem indeed, which actually happens with all of our dialogs
(try paragraph settings, for example).

Or document settings, for that matter. This is a regression too. Lyx 1.5
does not have this problem, because it is impossible to use the OK
button until you actually changes something. Looks like 1.6 lost this for some dialog. The child document dialog doens't have this particular problem though.

Helge Hafting

Reply via email to