Am Freitag, dem 21.05.2021 um 10:31 +0200 schrieb Jean-Marc Lasgouttes:
> The code is still here, so the question is relevant. It is not a bug
> though, it just seems to me that the code is needlessly complicated.
I cannot remember why I did that. I would need to investigate as well.
Should have
Le 21/05/2021 à 08:13, Jürgen Spitzmüller a écrit :
Am Donnerstag, dem 20.05.2021 um 12:44 +0200 schrieb Jean-Marc
Lasgouttes:
The new code seems safe enough. I just have a question. Why the test
for
size == 1 below:
if (arguments.size() == 1)
arguments.clear();
Am Donnerstag, dem 20.05.2021 um 12:44 +0200 schrieb Jean-Marc
Lasgouttes:
> The new code seems safe enough. I just have a question. Why the test
> for
> size == 1 below:
> if (arguments.size() == 1)
> arguments.clear();
> else if (!arguments.empty())
>
deprecation fix (this is the last one I am aware of)
This uses QProcess::startDetached(cmd, args) instead of
QProcess::startDetached(cmd + args) for Qt >= 5.15.
I have a question though. I see that this new form already exists in Qt4
https://doc.qt.io/archives/qt-4.8/qprocess.html
Now that I tried
Le 18/05/2021 à 15:57, Jürgen Spitzmüller a écrit :
Am Dienstag, dem 18.05.2021 um 15:48 +0200 schrieb Jean-Marc
Lasgouttes:
Both versions of QProcess::startDetached, depending on wherther Qt>=
5.15 or not (I can see that we can get rid of it when we are limited
to
Qt >= 5.15, but you
On 5/18/21 9:49 AM, Jean-Marc Lasgouttes wrote:
> Le 18/05/2021 à 15:25, Jürgen Spitzmüller a écrit :
>> Am Dienstag, dem 18.05.2021 um 14:27 +0200 schrieb Jean-Marc
>> Lasgouttes:
>>> In this case, having a single code path is a good thing IMO. Do we
>>> want
>>> to keep both versions until Qt5 su
Le 18/05/2021 à 15:25, Jürgen Spitzmüller a écrit :
Am Dienstag, dem 18.05.2021 um 14:27 +0200 schrieb Jean-Marc
Lasgouttes:
In this case, having a single code path is a good thing IMO. Do we
want
to keep both versions until Qt5 support is deleted?
What do you mean by "both versions"?
Before
Am Dienstag, dem 18.05.2021 um 14:27 +0200 schrieb Jean-Marc
Lasgouttes:
> In this case, having a single code path is a good thing IMO. Do we
> want
> to keep both versions until Qt5 support is deleted?
What do you mean by "both versions"?
Jürgen
signature.asc
Description: This is a digitally
Le 18/05/2021 à 13:52, Jürgen Spitzmüller a écrit :
I think that having the correct bounds will help us in the long term.
I think my rationale was to play safe and keep the deprecated function
until it was marked deprecated.
In this case, having a single code path is a good thing IMO. Do we w
2:14:42 2021 +0100
>
> Yet another deprecation fix (this is the last one I am aware of)
>
>
> This uses QProcess::startDetached(cmd, args) instead of
> QProcess::startDetached(cmd + args) for Qt >= 5.15.
>
> I have a question though. I see that this new form already
QProcess::startDetached(cmd, args) instead of
QProcess::startDetached(cmd + args) for Qt >= 5.15.
I have a question though. I see that this new form already exists in Qt4
https://doc.qt.io/archives/qt-4.8/qprocess.html
So, why use the conditionning on Qt 5.15 at all?
More generally, I am
On Tue, Mar 18, 2014 at 10:39:43PM +0100, Vincent van Ravesteijn wrote:
> See attached.
>
> Any comments ?
Looks fine. I would simply add a comment in the code explaining why
Windows is treated differently.
--
Enrico
See attached.
Any comments ?
Vincent
>From f1ae03c5ff07b3bfc420b3e448e863f0e1db6975 Mon Sep 17 00:00:00 2001
From: Vincent van Ravesteijn
Date: Tue, 18 Mar 2014 22:32:57 +0100
Subject: [PATCH] Do not use QProcess::startDetached on Windows
QProcess::startDetached cannot provide environm
Peter Kuemmel wrote:
> This is the problem with the quotes. which could be solved by
> 1. isolate each argument
This would be a sane approach anyway, IMHO.
Jürgen
Original-Nachricht
> Datum: Mon, 11 May 2009 19:44:55 +0200
> Von: Kornel Benko
> An: lyx-devel@lists.lyx.org
> Betreff: QProcess
> I still think, it are the quotes, which are _not_ handled in QProcess.
>
> 1.) Compile lyx with QProcess enabled.
> 2.)
I still think, it are the quotes, which are _not_ handled in QProcess.
1.) Compile lyx with QProcess enabled.
2.) Strace -o xx.qprocess -f lyx.
open file
export as e.g. pdf
exit lyx
3.) egrep tex2pdf xx.qprocess| egrep execve
==>
16424 execve(&qu
16 matches
Mail list logo
