Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 cannot make sense of this bug report. Firstly, the reported missing API was actually there. Indeed, that code was being compiled on Vista long before Win7 was released. Secondly, one could still compile LyX using and old Qt, so the requirements can differ. For what I know, LyX could actually be compiled on Vista, because all required APIs are there. If one cannot do that because he uses a recent Qt version that does not support Vista, that's another story. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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. BTW, our download page says that we only support windows 7 and later since June 2016. A relevant bug: https://www.lyx.org/trac/ticket/10186 JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 possible to compile LyX so that it runs under MacOS X > 10.4? But this has a meaning only if we know someone who provides this (even > through macports and friends, actually). I have elder versions of Mac OS available to test it. 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: error: no member named ‚move‘ in namespace ’std’ I don’t know if it makes sense to go back further at this point. From the point of security and inter-operability its not sensible to use those old systems anyway. It’s a little bit difficult to make a correct statement. From my point of view its the goal to build a LyX package ready to use for the user w/o compiler and other developer utilities. So I have to be able to build Qt + LyX on my own. I want to use Apple utilities to build the whole thing. I doubt it’s possible to get macports or homebrew ready to run on very old Mac OS versions. This would be an option to get modern compiler versions to build current LyX from source. I’m unable to test this. ATM, I’m able to build LyX on Mac OS 10.11.6 (El Capitan 2015). Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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, 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 directory names. On the other hand, > >>> QFileInfo::canonicalFilePath() does not resolve junctions (directory > >>> symlinks). > >> > >> Dropping support for Windows Xp, the attached patch works for me with > >> both files and directories. I am going to apply it, as I think it is > >> not controversial, given that MS dropped support for Win7 these year > >> (while we still support both WinVista and Win7). > > > > I have no definitive idea about that, but you should update README if > > you apply it. > > I am not totally sure, but I seem to recall that Uwe stopped pledging > support for XP quite some time ago. There was some specific reason, I > think, but I can't recall what it was. I don,t either, but since 5873a382 it won't even start on Xp and earlier versions. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 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 directory names. On the other hand, >>> QFileInfo::canonicalFilePath() does not resolve junctions (directory >>> symlinks). >> >> Dropping support for Windows Xp, the attached patch works for me with >> both files and directories. I am going to apply it, as I think it is >> not controversial, given that MS dropped support for Win7 these year >> (while we still support both WinVista and Win7). > > I have no definitive idea about that, but you should update README if > you apply it. I am not totally sure, but I seem to recall that Uwe stopped pledging support for XP quite some time ago. There was some specific reason, I think, but I can't recall what it was. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 this has a meaning only if we know someone who provides this (even through macports and friends, actually). JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 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 directory names. On the other hand, QFileInfo::canonicalFilePath() does not resolve junctions (directory symlinks). >>> Dropping support for Windows Xp, the attached patch works for me with >>> both files and directories. I am going to apply it, as I think it is >>> not controversial, given that MS dropped support for Win7 these year >>> (while we still support both WinVista and Win7). >> >> I have no definitive idea about that, but you should update README if you >> apply it. >> >> Stephan, do we still support MacOS X 10.4, BTW? > > I don’t think so. What do you mean with support? At build time or at runtime? Ah sorry, I see now. You refer to the README file. 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? Stephan > The LyX 2.3 package I’ve created requires 10.10 at least and 64-bit X86 cpu. > > Qt has its own minimum versions. For 5.12 I cannot look it up, ATM. -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 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 directory names. On the other hand, >>> QFileInfo::canonicalFilePath() does not resolve junctions (directory >>> symlinks). >> Dropping support for Windows Xp, the attached patch works for me with >> both files and directories. I am going to apply it, as I think it is >> not controversial, given that MS dropped support for Win7 these year >> (while we still support both WinVista and Win7). > > I have no definitive idea about that, but you should update README if you > apply it. > > Stephan, do we still support MacOS X 10.4, BTW? I don’t think so. What do you mean with support? At build time or at runtime? The LyX 2.3 package I’ve created requires 10.10 at least and 64-bit X86 cpu. Qt has its own minimum versions. For 5.12 I cannot look it up, ATM. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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. Mystery solved. On Windows, our implementation of realPath() works only with file names but does not work with directory names. On the other hand, QFileInfo::canonicalFilePath() does not resolve junctions (directory symlinks). Dropping support for Windows Xp, the attached patch works for me with both files and directories. I am going to apply it, as I think it is not controversial, given that MS dropped support for Win7 these year (while we still support both WinVista and Win7). I have no definitive idea about that, but you should update README if you apply it. Stephan, do we still support MacOS X 10.4, BTW? JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 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? > >> > >> Yes, at the time it was not possible using Qt in src/support. > > > > Hmmm. That does not seem to be the only reason. I now checked > > QFileInfo::canonicalFilePath() and it does not work on Windows. > > I created a junction but it is not resolved. > > That’s a strong argument to not rely on Qt completely. > > IMO, the documentation of it promise to do it better. > > https://doc.qt.io/qt-5/qfileinfo.html#canonicalFilePath > > "Returns the canonical path including the file name, i.e. an absolute > path without symbolic links or redundant "." or ".." elements." Just for correctness, the above statement is true, because it only speaks about symbolic links, which are actually resolved. The point is that real symbolic links can only be created with administrator provileges while junctions can be created by everyone. So, technically speaking, they tell the truth, but not the whole truth. Perhaps that's the reason they call the method canonicalFilePath() rather than realPath(). However, there's another problem with real symlinks. If they point to a directory and are the last component of a path, they are not recognized as directories. This problem does not occur with junctions. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 class? E.g. canonicalFilePath() and >>> friends? Are there historical reasons only? >> >> Yes, at the time it was not possible using Qt in src/support. > > Hmmm. That does not seem to be the only reason. I now checked > QFileInfo::canonicalFilePath() and it does not work on Windows. > I created a junction but it is not resolved. That’s a strong argument to not rely on Qt completely. IMO, the documentation of it promise to do it better. https://doc.qt.io/qt-5/qfileinfo.html#canonicalFilePath "Returns the canonical path including the file name, i.e. an absolute path without symbolic links or redundant "." or ".." elements." Thank you for checking that. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 implementation of realPath() works only with
> file names but does not work with directory names. On the other hand,
> QFileInfo::canonicalFilePath() does not resolve junctions (directory
> symlinks).
Dropping support for Windows Xp, the attached patch works for me with
both files and directories. I am going to apply it, as I think it is
not controversial, given that MS dropped support for Win7 these year
(while we still support both WinVista and Win7).
--
Enrico
diff --git a/src/support/os.cpp b/src/support/os.cpp
index 7e8fb8af57..616b9c6936 100644
--- a/src/support/os.cpp
+++ b/src/support/os.cpp
@@ -11,6 +11,10 @@
#include
+#ifdef _WIN32
+# define _WIN32_WINNT 0x0600
+#endif
+
#include "support/convert.h"
#include "support/debug.h"
#include "support/filetools.h"
diff --git a/src/support/os_win32.cpp b/src/support/os_win32.cpp
index e15af13acf..b57ddba9b0 100644
--- a/src/support/os_win32.cpp
+++ b/src/support/os_win32.cpp
@@ -38,6 +38,7 @@
#include
#include // _getdrive
+#include // GetFinalPathNameByHandle
#include // SHGetFolderPath
#include
#include
@@ -594,45 +595,18 @@ string real_path(string const & path)
// See http://msdn.microsoft.com/en-us/library/aa366789(VS.85).aspx
QString const qpath = get_long_path(toqstr(path));
HANDLE hpath = CreateFileW((wchar_t *) qpath.utf16(), GENERIC_READ,
- FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
+ FILE_SHARE_READ, NULL, OPEN_EXISTING,
+ FILE_FLAG_BACKUP_SEMANTICS, NULL);
if (hpath == INVALID_HANDLE_VALUE) {
// The file cannot be accessed.
return path;
}
- // Get the file size.
- DWORD size_hi = 0;
- DWORD size_lo = GetFileSize(hpath, &size_hi);
-
- if (size_lo == 0 && size_hi == 0) {
- // A zero-length file cannot be mapped.
- CloseHandle(hpath);
- return path;
- }
-
- // Create a file mapping object.
- HANDLE hmap = CreateFileMapping(hpath, NULL, PAGE_READONLY, 0, 1, NULL);
-
- if (!hmap) {
- CloseHandle(hpath);
- return path;
- }
-
- // Create a file mapping to get the file name.
- void * pmem = MapViewOfFile(hmap, FILE_MAP_READ, 0, 0, 1);
-
- if (!pmem) {
- CloseHandle(hmap);
- CloseHandle(hpath);
- return path;
- }
-
TCHAR realpath[MAX_PATH + 1];
- if (!GetMappedFileName(GetCurrentProcess(), pmem, realpath, MAX_PATH)) {
- UnmapViewOfFile(pmem);
- CloseHandle(hmap);
+ DWORD size = GetFinalPathNameByHandle(hpath, realpath, MAX_PATH,
VOLUME_NAME_NT );
+ if (size > MAX_PATH) {
CloseHandle(hpath);
return path;
}
@@ -678,8 +652,6 @@ string real_path(string const & path)
while (*p++) ;
} while (!found && *p);
}
- UnmapViewOfFile(pmem);
- CloseHandle(hmap);
CloseHandle(hpath);
string const retpath = subst(string(realpath), '\\', '/');
return FileName::fromFilesystemEncoding(retpath).absFileName();
diff --git a/src/support/os_win32.h b/src/support/os_win32.h
index 42016f7094..6f92b90abb 100644
--- a/src/support/os_win32.h
+++ b/src/support/os_win32.h
@@ -36,13 +36,13 @@
*/
#if defined(__MINGW32__) || defined(__CYGWIN__) || defined(__CYGWIN32__)
# if defined(WINVER)
-# if WINVER < 0x0500
-# error WINVER must be >= 0x0500
+# if WINVER < 0x0600
+# error WINVER must be >= 0x0600
# endif
# else
-# define WINVER 0x0500
+# define WINVER 0x0600
# endif
-# define _WIN32_IE 0x0500
+# define _WIN32_IE 0x0600
#endif
#include
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 directory names. On the other hand, QFileInfo::canonicalFilePath() does not resolve junctions (directory symlinks). -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 historical reasons only? > > Yes, at the time it was not possible using Qt in src/support. Hmmm. That does not seem to be the only reason. I now checked QFileInfo::canonicalFilePath() and it does not work on Windows. I created a junction but it is not resolved. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 +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 linux and cygwin, but does not on native windows. Inserting some debug statements just before file_name and realtmp are compared produces the following (I use C:/cygwin/tmp as the tempdir): file_name: C:/cygwin/tmp/LYX_TM~1.VSQ/LYX_TM~1/MANUSC~1.TEX realtmp: C:/cygwin/tmp/lyx_tmpdir.vsQUbXBjkoun Seemingly, the real path of file_name is returned in the short form, while that of realtmp is not. I don't know why. >>> >>> Replacing the following two lines: >>> >>> file_name = os::internal_path(trim(argument.substr(0, i))); >>> file_name = FileName(file_name).realPath(); >>> >>> with >>> file_name = os::internal_path(FileName(trim(argument.substr(0, >>> i))).realPath()); >>> >>> it works also on native windows. >> >> So, with this modification the patch would be acceptable? > > Yes, I think so. I’ve put it in with commit f2f861f017. Thank you for your help. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 fixes behind paywall will make things even worse. I totally agree with this. Qt is a black box. When is works, all is fine. When it does not, we have to guess when it stopped to work and why. Text painting in work area is a pain, for example. So I would say that if we have nightmarish piece of code (which might be the case here) then it make sense to Qt-fy it. This is what I thought with the text-painting/string-breaking stuff, and now we have to code by hand the word breaking rules in CJK (#11593). And we have to work around weird bugs. We have also some very weird bugs related to Qt unicode handling. The advantage of C++ std library here is that everything is dictated by a standard and every bug is something that has to be fixed. So we can basically rely on the behavior of the methods. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 Qt elements used. Why don???t we rely > > >> on the services of QFileInfo class? E.g. canonicalFilePath() and > > >> friends? Are there historical reasons only? > > > Yes, at the time it was not possible using Qt in src/support. > > > > Did we make an 'official' decision about this? If so, has it been > > recorded somewhere, like the development notes in the repo? If we're > > really prepared to allow Qt pretty much everywhere---i.e., after all > > these years, we're willing to admit that LyX is a Qt-based app---then > > there may well be a lot of simplifications we could make, maybe in the > > 2.5 cycle. Of course, that would make us more vulnerable to Qt bugs > > In a developers meeting at the end of 2008 it was decided that Qt could > be used if there were good reasons for it: > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg160412.html In my memory it was mainly Andre's push while others were either indiferent or reserved, but there was no one who would directly protest... Now we have another 10+ years of experience with Qt evolution. 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 fixes behind paywall will make things even worse. So I would say that if we have nightmarish piece of code (which might be the case here) then it make sense to Qt-fy it. But making general Qt-fication as a desired goal for next major release or similar does not strike me as a good idea from stability POV. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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? E.g. canonicalFilePath() and > >> friends? Are there historical reasons only? > > Yes, at the time it was not possible using Qt in src/support. > > Did we make an 'official' decision about this? If so, has it been > recorded somewhere, like the development notes in the repo? If we're > really prepared to allow Qt pretty much everywhere---i.e., after all > these years, we're willing to admit that LyX is a Qt-based app---then > there may well be a lot of simplifications we could make, maybe in the > 2.5 cycle. Of course, that would make us more vulnerable to Qt bugs In a developers meeting at the end of 2008 it was decided that Qt could be used if there were good reasons for it: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg160412.html But at the end of 2011 its use was still frowned upon: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg171844.html -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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? > Yes, at the time it was not possible using Qt in src/support. Did we make an 'official' decision about this? If so, has it been recorded somewhere, like the development notes in the repo? If we're really prepared to allow Qt pretty much everywhere---i.e., after all these years, we're willing to admit that LyX is a Qt-based app---then there may well be a lot of simplifications we could make, maybe in the 2.5 cycle. Of course, that would make us more vulnerable to Qt bugs Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 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 linux and cygwin, but does not on native windows. > >> Inserting some debug statements just before file_name and realtmp are > >> compared produces the following (I use C:/cygwin/tmp as the tempdir): > >> > >> file_name: C:/cygwin/tmp/LYX_TM~1.VSQ/LYX_TM~1/MANUSC~1.TEX > >> realtmp: C:/cygwin/tmp/lyx_tmpdir.vsQUbXBjkoun > >> > >> Seemingly, the real path of file_name is returned in the short form, while > >> that of realtmp is not. I don't know why. > > > > Replacing the following two lines: > > > > file_name = os::internal_path(trim(argument.substr(0, i))); > > file_name = FileName(file_name).realPath(); > > > > with > > file_name = os::internal_path(FileName(trim(argument.substr(0, > > i))).realPath()); > > > > it works also on native windows. > > So, with this modification the patch would be acceptable? Yes, I think so. > > Still, why realPath() returns a short path name in one case and not in the > > other case remains a mystery. > > A lookup of the implementation of it in os_win32.cpp shows the beauty > of the Windows APIs. =8( > > 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? Yes, at the time it was not possible using Qt in src/support. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
> 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 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 linux and cygwin, but does not on native windows. >> Inserting some debug statements just before file_name and realtmp are >> compared produces the following (I use C:/cygwin/tmp as the tempdir): >> >> file_name: C:/cygwin/tmp/LYX_TM~1.VSQ/LYX_TM~1/MANUSC~1.TEX >> realtmp: C:/cygwin/tmp/lyx_tmpdir.vsQUbXBjkoun >> >> Seemingly, the real path of file_name is returned in the short form, while >> that of realtmp is not. I don't know why. > > Replacing the following two lines: > > file_name = os::internal_path(trim(argument.substr(0, i))); > file_name = FileName(file_name).realPath(); > > with > file_name = os::internal_path(FileName(trim(argument.substr(0, > i))).realPath()); > > it works also on native windows. So, with this modification the patch would be acceptable? I’ve attached it with your modification. > Apparently, the only purpose of > internal_path() on windows is returning the long form of the path > (other than converting backslashes into slashes). Yes, indeed. The implementation of internal_path() on windows uses the GetLongPathNameW() function. https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getlongpathnamew > Still, why realPath() returns a short path name in one case and not in the > other case remains a mystery. A lookup of the implementation of it in os_win32.cpp shows the beauty of the Windows APIs. =8( 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? Stephan goToFileRow-6.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 if you can test if it breaks something used > > to work. > > It works for me on linux and cygwin, but does not on native windows. > Inserting some debug statements just before file_name and realtmp are > compared produces the following (I use C:/cygwin/tmp as the tempdir): > > file_name: C:/cygwin/tmp/LYX_TM~1.VSQ/LYX_TM~1/MANUSC~1.TEX > realtmp: C:/cygwin/tmp/lyx_tmpdir.vsQUbXBjkoun > > Seemingly, the real path of file_name is returned in the short form, while > that of realtmp is not. I don't know why. Replacing the following two lines: file_name = os::internal_path(trim(argument.substr(0, i))); file_name = FileName(file_name).realPath(); with file_name = os::internal_path(FileName(trim(argument.substr(0, i))).realPath()); it works also on native windows. Apparently, the only purpose of internal_path() on windows is returning the long form of the path (other than converting backslashes into slashes). Still, why realPath() returns a short path name in one case and not in the other case remains a mystery. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
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 linux and cygwin, but does not on native windows. Inserting some debug statements just before file_name and realtmp are compared produces the following (I use C:/cygwin/tmp as the tempdir): file_name: C:/cygwin/tmp/LYX_TM~1.VSQ/LYX_TM~1/MANUSC~1.TEX realtmp: C:/cygwin/tmp/lyx_tmpdir.vsQUbXBjkoun Seemingly, the real path of file_name is returned in the short form, while that of realtmp is not. I don't know why. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
