On Mon, Feb 24, 2020 at 11:19:50AM +0100, Jean-Marc Lasgouttes wrote:
>
> BTW, our download page says that we only support windows 7 and later since
> June 2016.
But the sources would still allow compiling with Xp and earlier versions.
> A relevant bug: https://www.lyx.org/trac/ticket/10186
I
Le 24/02/2020 à 10:57, Stephan Witt a écrit :
On Mac OS 10.8.5 (2012+) with Apple clang 4.0 the build
of lyx-2.3.4.2 fails with compiler errors in boost:
ATM, I’m able to build LyX on Mac OS 10.11.6 (El Capitan 2015).
Thanks for checking. I guess we can update README and the download page.
Am 23.02.2020 um 16:07 schrieb Jean-Marc Lasgouttes :
>
> Le 23/02/2020 à 15:42, Stephan Witt a écrit :
>> What’s the audience of this file?
>> Perhaps it’s possible to download a LyX for 10.4 - but is this the
>> intention of the authors of this list of requirements?
>
> The question is: is it
On Sun, Feb 23, 2020 at 12:52:46PM -0500, Richard Kimberly Heck wrote:
> On 2/23/20 7:50 AM, Jean-Marc Lasgouttes wrote:
> > Le 23/02/2020 à 11:40, Enrico Forestieri a écrit :
> >> On Sun, Feb 23, 2020 at 12:35:53AM +0100, Enrico Forestieri wrote:
> >>> On Tue, Feb 18, 2020 at 07:55:13PM +0100,
On 2/23/20 7:50 AM, Jean-Marc Lasgouttes wrote:
> Le 23/02/2020 à 11:40, Enrico Forestieri a écrit :
>> On Sun, Feb 23, 2020 at 12:35:53AM +0100, Enrico Forestieri wrote:
>>> On Tue, Feb 18, 2020 at 07:55:13PM +0100, Enrico Forestieri wrote:
Still, why realPath() returns a short path
Le 23/02/2020 à 15:42, Stephan Witt a écrit :
What’s the audience of this file?
Perhaps it’s possible to download a LyX for 10.4 - but is this the
intention of the authors of this list of requirements?
The question is: is it possible to compile LyX so that it runs under
MacOS X 10.4? But
Am 23.02.2020 um 15:29 schrieb Stephan Witt :
>
> Am 23.02.2020 um 13:50 schrieb Jean-Marc Lasgouttes :
>>
>> Le 23/02/2020 à 11:40, Enrico Forestieri a écrit :
>>> On Sun, Feb 23, 2020 at 12:35:53AM +0100, Enrico Forestieri wrote:
On Tue, Feb 18, 2020 at 07:55:13PM +0100, Enrico Forestieri
Am 23.02.2020 um 13:50 schrieb Jean-Marc Lasgouttes :
>
> Le 23/02/2020 à 11:40, Enrico Forestieri a écrit :
>> On Sun, Feb 23, 2020 at 12:35:53AM +0100, Enrico Forestieri wrote:
>>> On Tue, Feb 18, 2020 at 07:55:13PM +0100, Enrico Forestieri wrote:
Still, why realPath() returns a
Le 23/02/2020 à 11:40, Enrico Forestieri a écrit :
On Sun, Feb 23, 2020 at 12:35:53AM +0100, Enrico Forestieri wrote:
On Tue, Feb 18, 2020 at 07:55:13PM +0100, Enrico Forestieri wrote:
Still, why realPath() returns a short path name in one case and not in the
other case remains a mystery.
On Sun, Feb 23, 2020 at 12:20:16PM +0100, Stephan Witt wrote:
> Am 23.02.2020 um 00:27 schrieb Enrico Forestieri :
> >
> > On Thu, Feb 20, 2020 at 08:24:41AM +0100, Enrico Forestieri wrote:
> >> On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
> >>>
> >>> What I wonder: there are
Am 23.02.2020 um 00:27 schrieb Enrico Forestieri :
>
> On Thu, Feb 20, 2020 at 08:24:41AM +0100, Enrico Forestieri wrote:
>> On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
>>>
>>> What I wonder: there are the Qt elements used. Why don’t we rely
>>> on the services of QFileInfo
On Sun, Feb 23, 2020 at 12:35:53AM +0100, Enrico Forestieri wrote:
> On Tue, Feb 18, 2020 at 07:55:13PM +0100, Enrico Forestieri wrote:
> >
> > Still, why realPath() returns a short path name in one case and not in the
> > other case remains a mystery.
>
> Mystery solved. On Windows, our
On Tue, Feb 18, 2020 at 07:55:13PM +0100, Enrico Forestieri wrote:
>
> Still, why realPath() returns a short path name in one case and not in the
> other case remains a mystery.
Mystery solved. On Windows, our implementation of realPath() works only with
file names but does not work with
On Thu, Feb 20, 2020 at 08:24:41AM +0100, Enrico Forestieri wrote:
> On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
> >
> > What I wonder: there are the Qt elements used. Why don’t we rely
> > on the services of QFileInfo class? E.g. canonicalFilePath() and
> > friends? Are there
Am 20.02.2020 um 08:24 schrieb Enrico Forestieri :
>
> On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
>>
>>> Am 18.02.2020 um 19:55 schrieb Enrico Forestieri :
>>>
>>> On Tue, Feb 18, 2020 at 07:36:54PM +0100, Enrico Forestieri wrote:
On Tue, Feb 18, 2020 at 09:43:07AM
Le 20/02/2020 à 14:42, Pavel Sanda a écrit :
This is my personal opinion and others might see it differently but I am
somewhat frustrated with appearing regressions that are not getting fixed even
if properly reported to the bug tracker and the recent decision to hide LTS
releases with stability
On Thu, Feb 20, 2020 at 01:01:27PM +0100, Enrico Forestieri wrote:
> On Thu, Feb 20, 2020 at 03:09:56AM -0500, Richard Kimberly Heck wrote:
> > On 2/20/20 2:24 AM, Enrico Forestieri wrote:
> > > On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
> > >
> > >> What I wonder: there are the
On Thu, Feb 20, 2020 at 03:09:56AM -0500, Richard Kimberly Heck wrote:
> On 2/20/20 2:24 AM, Enrico Forestieri wrote:
> > On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
> >
> >> What I wonder: there are the Qt elements used. Why don’t we rely
> >> on the services of QFileInfo class?
On 2/20/20 2:24 AM, Enrico Forestieri wrote:
> On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
>
>> What I wonder: there are the Qt elements used. Why don’t we rely
>> on the services of QFileInfo class? E.g. canonicalFilePath() and
>> friends? Are there historical reasons only?
>
On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
>
> > Am 18.02.2020 um 19:55 schrieb Enrico Forestieri :
> >
> > On Tue, Feb 18, 2020 at 07:36:54PM +0100, Enrico Forestieri wrote:
> >> On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote:
> >>>
> >>> Because I’m unable to
> Am 18.02.2020 um 19:55 schrieb Enrico Forestieri :
>
> On Tue, Feb 18, 2020 at 07:36:54PM +0100, Enrico Forestieri wrote:
>> On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote:
>>>
>>> Because I’m unable to test it with other PDF viewers with SyncTeX
>>> support and/or to test it
On Tue, Feb 18, 2020 at 07:36:54PM +0100, Enrico Forestieri wrote:
> On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote:
> >
> > Because I’m unable to test it with other PDF viewers with SyncTeX
> > support and/or to test it on Linux and Windows I post the patch
> > and it would be nice
On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote:
>
> Because I’m unable to test it with other PDF viewers with SyncTeX
> support and/or to test it on Linux and Windows I post the patch
> and it would be nice if you can test if it breaks something used
> to work.
It works for me on
Hi all,
because of a change in behavior of Qt on Mac we have to make the
buffer lookup for a given temporary file more robust.
The root cause of this is the fact that on Mac temporary files
are reachable by more then one file name because of directory
/var being a symbolic link to /private/var.
24 matches
Mail list logo
