Fwd: fr.po for master

[Richard Heck]

Please see below about a compilation error.

Richard


 Forwarded Message 
Subject:fr.po for master
Date:   Tue, 29 Dec 2015 09:17:57 +
From:   Jean-Pierre Chrétien 
Reply-To:   jeanpierre.chret...@free.fr
To: po-upda...@lyx.org 



Hello

Attached is an update of fr.po for master following Uwe's mail.
I did not check extensively for shortcut conflicts, I will do it while 
reviewing 
the doc.

I got an error message while running autogen.sh, which prevented further 
compilation of lyx-2.2.0dev :

http://thread.gmane.org/gmane.editors.lyx.cvs/42301/focus=159471

I had to remove one of the references to relocatable.c in the
3rdparty/libiconv/Makefile.am file to be able to compile.

I have these versions here :
Using automake (GNU automake) 1.11.6
Using autoconf (GNU Autoconf) 2.69

-- 
Regards
Jean-Pierre

Re: Fwd: fr.po for master

[Jean-Marc Lasgouttes]

Le 29/12/2015 15:56, Richard Heck a écrit :


Please see below about a compilation error.


Hi,

I have a patch in hand, it will be fixed shortly.

JMarc

Re: Can anyone build with mingw?

[Scott Kostyshak]

On Mon, Dec 28, 2015 at 12:40:34PM +0100, Peter Kümmel wrote:
> Am 28. Dezember 2015 11:41:02 MEZ, schrieb Kornel Benko :
> >Am Montag, 28. Dezember 2015 um 05:24:59, schrieb Scott Kostyshak
> >
> >> On Mon, Dec 28, 2015 at 11:07:18AM +0100, Peter Kümmel wrote:
> >> > Am 28. Dezember 2015 07:28:55 MEZ, schrieb Scott Kostyshak
> >:
> >> > >On Sun, Dec 27, 2015 at 05:52:04AM -0500, Scott Kostyshak wrote:
> >> > >> Peter recently added a script to build LyX with mingw, but it
> >does
> >> > >not
> >> > >> work for me. Does it work for anyone else?
> >> > >> 
> >> > >> $ ./development/cmake/scripts/xmingw
> >> > >> Usage: xmingw 
> >> > >> $ ./development/cmake/scripts/xmingw  ./
> >> > >> -
> >> > >> -- Building LyX-2015.12.27-10.49
> >> > >> -
> >> > >> Checking mingw installation ...
> >> > >> 4.9.2
> >> > >> Checking Qt installation ...
> >> > >> .//../lyx-dependencies/Qt-5.5.1-i686-w64-mingw32/bin/qmake
> >> > >> ./development/cmake/scripts/xmingw: line 95: ./: Is a directory
> >> > >> Command failed
> >> > >> $ 
> >> > >> 
> >> > >> It seems xmingw wants a folder as an argument, but the
> >underlying
> >> > >qmake
> >> > >> command wants a .pro file?
> >> > >
> >> > >CC'ing Peter in case he doesn't follow this list.
> >> > >
> >> > >Scott
> >> > 
> >> > I only tested with an out of source build directory. Maybe it works
> >in your case with an absolute path.
> >> 
> >> Same error:
> >> 
> >> $ /home/scott/lyxbuilds/master/repo/development/cmake/scripts/xmingw
> >/home/scott/lyxbuilds/master/repo
> >> -
> >> -- Building LyX-2015.12.28-10.23
> >> -
> >> Checking mingw installation ...
> >> 4.9.2
> >> Checking Qt installation ...
> >>
> >/home/scott/lyxbuilds/master/repo/../lyx-dependencies/Qt-5.5.1-i686-w64-mingw32/bin/qmake
> >> /home/scott/lyxbuilds/master/repo/development/cmake/scripts/xmingw:
> >line
> >> 95: /home/scott/lyxbuilds/master/repo: Is a directory
> >> Command failed
> >> $
> >
> >I get something different:
> >$ /usr2/src/lyx/lyx-git/development/cmake/scripts/xmingw
> >/usr2/src/lyx/lyx-git
> >...
> >Checking Qt installation ...
> >/usr2/src/lyx/lyx-git/../lyx-dependencies/Qt-5.5.1-i686-w64-mingw32/bin/qmake
> >/usr2/src/lyx/lyx-git/development/cmake/scripts/xmingw: 95:
> >/usr2/src/lyx/lyx-git/development/cmake/scripts/xmingw:
> >/usr2/src/lyx/lyx-git: Permission denied
> >Command failed
> >
> >> Scott
> >
> > Kornel
> 
> Ah, the cmakebin variable is not set, a rest of the bot script. Replacing the 
> variable by cmake should fix it.

Yes this was the problem. There seem to be several unset variables. Can
we use
set -u
with /bin/sh or is that only for bash?
For example, $ver is not set for me.

Scott


signature.asc
Description: PGP signature

Re: Fwd: [Build #8773158] i386 build of lyx2.2 2.2.0~git20151230~ubuntu12.04.1 in ubuntu precise RELEASE [~lyx-devel/ubuntu/daily]

[Scott Kostyshak]

On Wed, Dec 30, 2015 at 08:09:15PM +0100, Liviu Andronic wrote:
> Dear all,
> This past week I've been getting daily build failures of LyX on Ubuntu
> Precise (see build log link below). The configure process finishes
> like this:
> configure: creating ./config.status
> config.status: error: cannot find input file: `Makefile.in'
> make[1]: *** [override_dh_auto_configure] Error 1
> make[1]: Leaving directory `/«PKGBUILDDIR»'
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> 
> Is there something that might have changed in a recent commit to
> generate such an error? Strangely, none of the other Ubuntu distros
> seems to be affected.
> 
> Regards,
> Liviu

We just had a thread a couple of days ago that we CC'ed you on. JMarc
posted a patch. Did you receive the emails? Maybe you wrote this email
before and it was just sent now.

Scott


signature.asc
Description: PGP signature

Re: lyx2lyx bug: duplicating some lyx properties

[Georg Baum]

Am 28.12.2015 um 08:27 schrieb Scott Kostyshak:

On Mon, Dec 28, 2015 at 08:25:11AM +0100, Kornel Benko wrote:

Am Montag, 28. Dezember 2015 um 02:02:45, schrieb Scott Kostyshak 


On Sun, Dec 27, 2015 at 05:39:06PM +0100, Kornel Benko wrote:

Am Sonntag, 27. Dezember 2015 um 11:23:36, schrieb Scott Kostyshak 



I see. I still think something is wrong with that format increase
though, or perhaps the trip back to 503. To reproduce, do:

cd lib/examples/fr
lyx -e lyx21x Foils.lyx
mv Foils.21.lyx Foils.lyx

Then
$ ctest -R "fr/Foils"
   3481 - EXAMPLES_export/examples/fr/Foils_pdf4_systemF (Failed)
   3483 - EXAMPLES_export/examples/fr/Foils_pdf5_systemF (Failed)


Hmm... Setting 'babel' as language package cures it for system fonts though.


So you think there is no bug? I don't understand the logic.


Sure there was a bug. I only played a little and found _one_ workaround.
But since Jürgen has corrected lyx2lyx, the bug did not show again.


Ah I did not realize. He fixed this bug too? Great.


I do not understand. What was wrong with lyx2lyx? I could not see any 
relevant commit.


The duplication of font settings from 500 to 501 is wanted. A round trip 
500->501->500 should produce an identical file, and this is what does 
indeed happen when I try by hand.



Georg

Re: lyx2lyx bug: duplicating some lyx properties

[Georg Baum]

Scott Kostyshak wrote:

> The test fails after doing lyx2lyx:
> 
> cd lib/examples/fr
> lyx -e lyx21x Foils.lyx
> mv Foils.21.lyx Foils.lyx
> 
> After doing a (manual) bisect, I narrowed the failure down to the 500 vs.
> 501 format change:
> 
> cd lib/examples/fr && git checkout Foils.lyx &&
> /home/scott/lyxbuilds/master/repo/lib/lyx2lyx/lyx2lyx -t 501 Foils.lyx >
> Foils.501.lyx && /home/scott/lyxbuilds/master/repo/lib/lyx2lyx/lyx2lyx -t
> 500 Foils.lyx > Foils.500.lyx
> 
> When I copy Foils.501.lyx to Foils.lyx and then run the tests, the tests
> pass. When I copy Foils.500.lyx to Foils.lyx and then run the tests, the
> tests fail.
> 
> I don't know if the difference comes from our testing framework or lyx2lyx
> or LyX.

OK, now I understand (thanks also to Kornel for the explanation).

This is what happens: When converting from 500 to 501, the font settings of 
the not used flavour are filled in from the fontdefaults list in lyx_2_2.py. 
Thus, after a 503->500->503 roundtrip, you get the attached patch, which 
makes the tests fail.

This is not a bug. The conversion 501->500 must be lossy, since the format 
500 is not able to store the font information of the "not used" flavour. 
Therefore, the only exports which are guaranteed to work after a conversion 
to format 500 are the ones of the used flavour (\use_non_tex_fonts false or 
true). The other flavour may fail.

IMHO it does not make sense to blindly test more and more combinations of 
conversions of the existing documents. I would rather put the energy in 
creating dedicated tests, e.g. for each lyx2lyx step. I must admit that I do 
not understand the current test strategy anymore, since there are several 
categories, and the test code became so complicated (e.g. running lyx2lyx in 
a loop or automagically changing document settings).


Georg
diff --git a/lib/examples/fr/Foils.lyx b/lib/examples/fr/Foils.lyx
index f211fdd..b14c35a 100644
--- a/lib/examples/fr/Foils.lyx
+++ b/lib/examples/fr/Foils.lyx
@@ -18,7 +18,7 @@
 \font_roman "default" "default"
 \font_sans "default" "default"
 \font_typewriter "default" "default"
-\font_math "auto" "default"
+\font_math "auto" "auto"
 \font_default_family default
 \use_non_tex_fonts false
 \font_sc false

Re: lyx2lyx bug: duplicating some lyx properties

[Scott Kostyshak]

On Thu, Dec 31, 2015 at 01:38:56PM +0100, Georg Baum wrote:
> Am 28.12.2015 um 08:27 schrieb Scott Kostyshak:
> >On Mon, Dec 28, 2015 at 08:25:11AM +0100, Kornel Benko wrote:
> >>Am Montag, 28. Dezember 2015 um 02:02:45, schrieb Scott Kostyshak 
> >>
> >>>On Sun, Dec 27, 2015 at 05:39:06PM +0100, Kornel Benko wrote:
> Am Sonntag, 27. Dezember 2015 um 11:23:36, schrieb Scott Kostyshak 
> 
> >
> >I see. I still think something is wrong with that format increase
> >though, or perhaps the trip back to 503. To reproduce, do:
> >
> >cd lib/examples/fr
> >lyx -e lyx21x Foils.lyx
> >mv Foils.21.lyx Foils.lyx
> >
> >Then
> >$ ctest -R "fr/Foils"
> >   3481 - EXAMPLES_export/examples/fr/Foils_pdf4_systemF (Failed)
> >   3483 - EXAMPLES_export/examples/fr/Foils_pdf5_systemF (Failed)
> 
> Hmm... Setting 'babel' as language package cures it for system fonts 
> though.
> >>>
> >>>So you think there is no bug? I don't understand the logic.
> >>
> >>Sure there was a bug. I only played a little and found _one_ workaround.
> >>But since Jürgen has corrected lyx2lyx, the bug did not show again.
> >
> >Ah I did not realize. He fixed this bug too? Great.
> 
> I do not understand. What was wrong with lyx2lyx? I could not see any
> relevant commit.
> 
> The duplication of font settings from 500 to 501 is wanted. A round trip
> 500->501->500 should produce an identical file, and this is what does indeed
> happen when I try by hand.

The test fails after doing lyx2lyx:

cd lib/examples/fr
lyx -e lyx21x Foils.lyx
mv Foils.21.lyx Foils.lyx

After doing a (manual) bisect, I narrowed the failure down to the 500 vs. 501 
format change:

cd lib/examples/fr && git checkout Foils.lyx && 
/home/scott/lyxbuilds/master/repo/lib/lyx2lyx/lyx2lyx -t 501 Foils.lyx > 
Foils.501.lyx && /home/scott/lyxbuilds/master/repo/lib/lyx2lyx/lyx2lyx -t 500 
Foils.lyx > Foils.500.lyx

When I copy Foils.501.lyx to Foils.lyx and then run the tests, the tests pass. 
When I copy Foils.500.lyx to Foils.lyx and then run the tests, the tests fail.

I don't know if the difference comes from our testing framework or lyx2lyx or 
LyX.

These are the failing tests:

ctest -R 'fr/Foils.lyx'

3487 - EXAMPLES_export/examples/fr/Foils_pdf4_systemF (Failed)
3489 - EXAMPLES_export/examples/fr/Foils_pdf5_systemF (Failed)

Scott


signature.asc
Description: PGP signature

[patch] origin again

[Georg Baum]

Sorry for opening a new thread, but gmane did already expire the old thread 
in the nntp interface, and I do not keep lyx-devel mails.

The attached patch implements the third option I described in the starting 
message of the original thread:

> - Do not change the paths in general if the files can be found using the
> relative paths. Has the additional benefit that this is also the wanted
> behaviour if I copy a whole directory of LyX files (including referenced
> graphics) to a new location. Disadvantage would be that the machinery does
> now depend on the presence of external files, and it is not guaranteed
> that the file that is found is the correct one.

It does not address Jean-Marcs concerns about the implicit behaviour:

> I really do not like that this /systemlyxdir thing has to be set on
> install by mofiying the file and that this setting is not accessible from
> the GUI. I'd prefer a scheme where the document is explicitly marked as
> lyxdoc and is handled differently depending on whether it is in its
> natural place or not. That would smell less like black magick.

This is something we should think of for a later release IMHO. For 2.2.0, we 
should ensure that /systemlyxdir is already set for all files in the source 
tar ball (at install time it is too late IMHO). It is easy to create a 
script doing that.

The patch does also make improve the behaviour for non-LyX-doc documents 
(imagine a user copying a whole project directory conataining LyX files with 
relative paths inside the project directory). These paths are damaged 
without the patch as well. Therefore it will not be obsolete if we introduce 
an explicit LyX_doc setting later.

I do not like that there are two similar methods Buffer::includedFilePath() 
and Buffer::getReferencedFileName(). All insets should use the same method, 
and the other one should be ditched, but the difference was already there 
before, and changing this now is too dangerous IMHO, so it is something for 
later as well.

OK to go in?


Georgdiff --git a/src/Buffer.cpp b/src/Buffer.cpp
index eac9821..b0f9ee9 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -1029,7 +1029,10 @@ bool Buffer::readDocument(Lexer & lex)
 	params().indiceslist().addDefault(B_("Index"));
 
 	// read main text
-	d->old_position = originFilePath();
+	if (FileName::isAbsolute(params().origin))
+		d->old_position = params().origin;
+	else
+		d->old_position = filePath();
 	bool const res = text().read(lex, errorList, d->inset);
 	d->old_position.clear();
 
@@ -3025,12 +3028,21 @@ string Buffer::filePath() const
 }
 
 
-string Buffer::originFilePath() const
+DocFileName Buffer::getReferencedFileName(string const & fn) const
 {
-	if (FileName::isAbsolute(params().origin))
-		return params().origin;
+	DocFileName result;
+	if (FileName::isAbsolute(fn) || !FileName::isAbsolute(params().origin))
+		result.set(fn, filePath());
+	else {
+		// filePath() ends with a path separator
+		FileName const test(filePath() + fn);
+		if (test.exists())
+			result.set(fn, filePath());
+		else
+			result.set(fn, params().origin);
+	}
 
-	return filePath();
+	return result;
 }
 
 
@@ -5067,13 +5079,23 @@ void Buffer::checkMasterBuffer()
 
 string Buffer::includedFilePath(string const & name, string const & ext) const
 {
+	if (d->old_position.empty() ||
+	equivalent(FileName(d->old_position), FileName(filePath(
+		return name;
+
 	bool isabsolute = FileName::isAbsolute(name);
-	// old_position already contains a trailing path separator
-	string const absname = isabsolute ? name : d->old_position + name;
+	// both old_position and filePath() end with a path separator
+	string absname = isabsolute ? name : d->old_position + name;
+
+	// if old_position is set to origin, we need to do the equivalent of
+	// getReferencedFileName() (see readDocument())
+	if (!isabsolute && d->old_position == params().origin) {
+		FileName const test(addExtension(filePath() + name, ext));
+		if (test.exists())
+			absname = filePath() + name;
+	}
 
-	if (d->old_position.empty()
-	|| equivalent(FileName(d->old_position), FileName(filePath()))
-	|| !FileName(addExtension(absname, ext)).exists())
+	if (!FileName(addExtension(absname, ext)).exists())
 		return name;
 
 	if (isabsolute)
diff --git a/src/Buffer.h b/src/Buffer.h
index 7450790..3f5ab22 100644
--- a/src/Buffer.h
+++ b/src/Buffer.h
@@ -66,6 +66,7 @@ class WorkAreaManager;
 }
 
 namespace support {
+class DocFileName;
 class FileName;
 class FileNameList;
 }
@@ -405,12 +406,14 @@ public:
 	/// It is always an absolute path.
 	std::string filePath() const;
 
-	/** Returns the path where the document was last saved.
-	 *  It may be different from filePath() if the document was later
-	 *  manually moved to a different location.
-	 *  It is always an absolute path.
+	/** Contructs a file name of a referenced file (child doc, included graphics etc).
+	 *  Absolute names are returned as is. If the name is relative, it is
+	 *  interpreted relative to filePath() 

Fwd: [Build #8773158] i386 build of lyx2.2 2.2.0~git20151230~ubuntu12.04.1 in ubuntu precise RELEASE [~lyx-devel/ubuntu/daily]

[Liviu Andronic]

Dear all,
This past week I've been getting daily build failures of LyX on Ubuntu
Precise (see build log link below). The configure process finishes
like this:
configure: creating ./config.status
config.status: error: cannot find input file: `Makefile.in'
make[1]: *** [override_dh_auto_configure] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


Is there something that might have changed in a recent commit to
generate such an error? Strangely, none of the other Ubuntu distros
seems to be affected.

Regards,
Liviu


-- Forwarded message --
From: Launchpad Buildd System 
Date: Wed, Dec 30, 2015 at 3:06 PM
Subject: [Build #8773158] i386 build of lyx2.2
2.2.0~git20151230~ubuntu12.04.1 in ubuntu precise RELEASE
[~lyx-devel/ubuntu/daily]
To: Liviu Andronic 



 * Source Package: lyx2.2
 * Version: 2.2.0~git20151230~ubuntu12.04.1
 * Architecture: i386
 * Archive: ~lyx-devel/ubuntu/daily
 * Component: main
 * State: Failed to build
 * Duration: 2 minutes
 * Build Log: 
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily/+build/8773158/+files/buildlog_ubuntu-precise-i386.lyx2.2_2.2.0%7Egit20151230%7Eubuntu12.04.1_BUILDING.txt.gz
 * Builder: https://launchpad.net/builders/lcy01-35
 * Source: not available



If you want further information about this situation, feel free to
contact a member of the Launchpad Buildd Administrators team.

--
i386 build of lyx2.2 2.2.0~git20151230~ubuntu12.04.1 in ubuntu precise RELEASE
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily/+build/8773158

You are receiving this email because your team LyX Team is the owner of
this archive.


-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Can anyone build with mingw?

[Peter Kümmel]

Am 28. Dezember 2015 11:41:02 MEZ, schrieb Kornel Benko :
>Am Montag, 28. Dezember 2015 um 05:24:59, schrieb Scott Kostyshak
>
>> On Mon, Dec 28, 2015 at 11:07:18AM +0100, Peter Kümmel wrote:
>> > Am 28. Dezember 2015 07:28:55 MEZ, schrieb Scott Kostyshak
>:
>> > >On Sun, Dec 27, 2015 at 05:52:04AM -0500, Scott Kostyshak wrote:
>> > >> Peter recently added a script to build LyX with mingw, but it
>does
>> > >not
>> > >> work for me. Does it work for anyone else?
>> > >> 
>> > >> $ ./development/cmake/scripts/xmingw
>> > >> Usage: xmingw 
>> > >> $ ./development/cmake/scripts/xmingw  ./
>> > >> -
>> > >> -- Building LyX-2015.12.27-10.49
>> > >> -
>> > >> Checking mingw installation ...
>> > >> 4.9.2
>> > >> Checking Qt installation ...
>> > >> .//../lyx-dependencies/Qt-5.5.1-i686-w64-mingw32/bin/qmake
>> > >> ./development/cmake/scripts/xmingw: line 95: ./: Is a directory
>> > >> Command failed
>> > >> $ 
>> > >> 
>> > >> It seems xmingw wants a folder as an argument, but the
>underlying
>> > >qmake
>> > >> command wants a .pro file?
>> > >
>> > >CC'ing Peter in case he doesn't follow this list.
>> > >
>> > >Scott
>> > 
>> > I only tested with an out of source build directory. Maybe it works
>in your case with an absolute path.
>> 
>> Same error:
>> 
>> $ /home/scott/lyxbuilds/master/repo/development/cmake/scripts/xmingw
>/home/scott/lyxbuilds/master/repo
>> -
>> -- Building LyX-2015.12.28-10.23
>> -
>> Checking mingw installation ...
>> 4.9.2
>> Checking Qt installation ...
>>
>/home/scott/lyxbuilds/master/repo/../lyx-dependencies/Qt-5.5.1-i686-w64-mingw32/bin/qmake
>> /home/scott/lyxbuilds/master/repo/development/cmake/scripts/xmingw:
>line
>> 95: /home/scott/lyxbuilds/master/repo: Is a directory
>> Command failed
>> $
>
>I get something different:
>$ /usr2/src/lyx/lyx-git/development/cmake/scripts/xmingw
>/usr2/src/lyx/lyx-git
>...
>Checking Qt installation ...
>/usr2/src/lyx/lyx-git/../lyx-dependencies/Qt-5.5.1-i686-w64-mingw32/bin/qmake
>/usr2/src/lyx/lyx-git/development/cmake/scripts/xmingw: 95:
>/usr2/src/lyx/lyx-git/development/cmake/scripts/xmingw:
>/usr2/src/lyx/lyx-git: Permission denied
>Command failed
>
>> Scott
>
>   Kornel

Ah, the cmakebin variable is not set, a rest of the bot script. Replacing the 
variable by cmake should fix it.

Re: Can anyone build with mingw?

[Kornel Benko]

Am Montag, 28. Dezember 2015 um 13:06:14, schrieb Kornel Benko 
> Am Montag, 28. Dezember 2015 um 12:56:01, schrieb Kornel Benko 
> 
> > 
> > So we need g++-mingw-w64-i686 package too (not only gcc-mingw-w64-i686)
> > 
> > Now it started ...
> > 
> 
> And stopped because of iconv.h
> /usr2/src/lyx/lyx-git/src/support/docstream.cpp:21:19: fatal error: iconv.h: 
> No such file or directory
>  #include 
> 
> It is created in the build dir, but apparently are the include paths not 
> correct
>   $ find . -name iconv.h -ls
>   17172787   12 -rw-r--r--   1 kornel   kornel   9690 Dec 28 12:55 
> ./3rdparty/libiconv/iconv.h
>   17302591   12 -rw-r--r--   1 kornel   kornel   9348 Dec 28 12:55 
> ./libiconv/include/iconv.h
> 
> Which is correct? They are different.

Turned out to be error on my side. I already have removed iconv from my local 
cmake-files.
For unix it was OK, but crosscompiling for mingw it was not.

Successfully built LyX.exe.

Kornel

signature.asc
Description: This is a digitally signed message part.

[PATCH] Bug 9907: Master-Child Closing Crash

[Richard Heck]

This is a repost now that the lists work again.

=

See http://www.lyx.org/trac/ticket/9907.

Here's a proper patch intended to fix this bug. It actually does a lot
less than it appears to do. The old BufferList::releaseChild(parent,
child) routine did a few different things: First, it checked whether the
child in question was open as a child of some other parent; if not, it
released it; if so, it set its parent to 0. The new patch replaces that
routine with BufferList::isOthersChild, which only does the first of
these things. The other tasks are performed by the caller, depending
upon the return value.

So the change made in Buffer.cpp (should!) actually make no difference
at all.

The advantage is that we can now check, in GuiView::closeBuffer, whether
the child is open as a child of some other Buffer before trying to close it.

Richard


>From d749c635dce01418b8623710d4287d1c9fd62cb3 Mon Sep 17 00:00:00 2001
From: Richard Heck 
Date: Sun, 20 Dec 2015 11:50:18 -0500
Subject: [PATCH] Fix bug 9907. The problem was that, when closing one Buffer,
 we were closing all of its children, even if they were open as children of
 some other Buffer.

---
 src/Buffer.cpp|  8 ++--
 src/BufferList.cpp| 47 ---
 src/BufferList.h  |  9 +
 src/frontends/qt4/GuiView.cpp | 26 +++-
 4 files changed, 50 insertions(+), 40 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index eac9821..115a542 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -517,8 +517,12 @@ Buffer::~Buffer()
 		Impl::BufferPositionMap::iterator end = d->children_positions.end();
 		for (; it != end; ++it) {
 			Buffer * child = const_cast(it->first);
-			if (theBufferList().isLoaded(child))
-theBufferList().releaseChild(this, child);
+			if (theBufferList().isLoaded(child)) { 
+			 if (theBufferList().isOthersChild(this, child))
+ child->setParent(0);
+			 else
+theBufferList().release(child);
+			}
 		}
 
 		if (!isClean()) {
diff --git a/src/BufferList.cpp b/src/BufferList.cpp
index 68a1e80..ff99a09 100644
--- a/src/BufferList.cpp
+++ b/src/BufferList.cpp
@@ -267,6 +267,28 @@ bool BufferList::exists(FileName const & fname) const
 }
 
 
+bool BufferList::isOthersChild(Buffer * parent, Buffer * child)
+{
+	LASSERT(parent, return false);
+	LASSERT(child, return false);
+	LASSERT(parent->isChild(child), return false);
+	
+	// Does child document have a different parent?
+	Buffer const * parent_ = child->parent();
+	if (parent_ && parent_ != parent)
+		return true;
+	
+	BufferStorage::iterator it = bstore.begin();
+	BufferStorage::iterator end = bstore.end();
+	for (; it != end; ++it) {
+		Buffer * buf = *it;
+		if (buf != parent && buf->isChild(child))
+			return true;
+	}
+	return false;
+}
+
+
 namespace {
 
 struct equivalent_to : public binary_function
@@ -364,31 +386,6 @@ int BufferList::bufferNum(FileName const & fname) const
 }
 
 
-bool BufferList::releaseChild(Buffer * parent, Buffer * child)
-{
-	LASSERT(parent, return false);
-	LASSERT(child, return false);
-	LASSERT(parent->isChild(child), return false);
-
-	// Child document has a different parent, don't close it.
-	Buffer const * parent_ = child->parent();
-	if (parent_ && parent_ != parent)
-		return false;
-
-	BufferStorage::iterator it = bstore.begin();
-	BufferStorage::iterator end = bstore.end();
-	for (; it != end; ++it) {
-		Buffer * buf = *it;
-		if (buf != parent && buf->isChild(child)) {
-			child->setParent(0);
-			return false;
-		}
-	}
-	release(child);
-	return true;
-}
-
-
 void BufferList::changed(bool update_metrics) const
 {
 	BufferStorage::const_iterator it = bstore.begin();
diff --git a/src/BufferList.h b/src/BufferList.h
index 242eff0..690bf6a 100644
--- a/src/BufferList.h
+++ b/src/BufferList.h
@@ -55,13 +55,14 @@ public:
 	/// \return 0 if the Buffer creation is not possible for whatever reason.
 	Buffer * newInternalBuffer(std::string const & s);
 
+	/// Is child a child of some Buffer other than parent?
+	/// NOTE: child must be a child of parent, and both must be non-null.
+	/// Otherwise we assert.
+	bool isOthersChild(Buffer * parent, Buffer * child);
+
 	/// delete a buffer
 	void release(Buffer * b);
 
-	/// Release \p child if it really is a child and is not used elsewhere.
-	/// \return true is the file was closed.
-	bool releaseChild(Buffer * parent, Buffer * child);
-
 	/// Close all open buffers.
 	void closeAll();
 
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index 548381b..c2101f3 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -2849,23 +2849,31 @@ bool GuiView::closeBuffer(Buffer & buf)
 		ListOfBuffers::const_iterator it = clist.begin();
 		ListOfBuffers::const_iterator const bend = clist.end();
 		for (; it != bend; ++it) {
-			// If a child is dirty, do not close
-			// without user intervention
-			//FIXME: 

Re: Change icon sizez in toolbars (not the three standard ones)

[Tom]

Hi Paola,

Did you ever found a solution for the problem?

Best,
Tom