Jürgen Spitzmüller wrote:
> > it will completely break eg version control handling.
>
> If so, we could for the time being keep an oldSystemcall method that is only
> used by vc until the problems are solved.
that was my proposal
pavel
On Sat, May 09, 2009 at 10:49:29PM +0200, Pavel Sanda wrote:
> again, this was not the problem. i'm all for having parallel processing, the
> argued cases were for _synchro_ calls switch from ::system to qprocess - there
> is no change wrt the ui appearance, only you have more general solution of
>
Pavel Sanda wrote:
> i haven't look on the QProcess yet, but if it works like execvp
AFAIU, It does not generally "work" like execvp, but it includes the
possibilitiy to work like that. QProcess looks quite flexible.
> it will completely break eg version control handling.
If so, we could for th
Andre Poenitz wrote:
> > i haven't look on the QProcess yet, but if it works like execvp
> > it will completely break eg version control handling.
>
> What is the special need of version control handling?
two issues -
1. from time to time we use more shell commands in one string. this
wont work
Kornel Benko wrote:
> I think, hanging on for some reason blocked version control should not prevent
> us to do other things with lyx. So I would prefer QProcess here too.
you are missing the point - i'm not preventing you to use qprocess. my quarrel
was how wide should be the usage. i spent quite
On 09/05/2009 22:23, Andre Poenitz wrote:
On Sat, May 09, 2009 at 09:21:33PM +0200, Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
if you implement only additional parameters for programs detected by
configure and then run some kind of execvp call rather than
On Sat, May 09, 2009 at 09:21:33PM +0200, Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > Pavel Sanda wrote:
> > > if you implement only additional parameters for programs detected by
> > > configure and then run some kind of execvp call rather than the normal
> > > system call, no additional pr
Am Samstag 09 Mai 2009 schrieb Pavel Sanda:
> Jürgen Spitzmüller wrote:
> > Pavel Sanda wrote:
> > > if you implement only additional parameters for programs detected by
> > > configure and then run some kind of execvp call rather than the normal
> > > system call, no additional program can be run
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > if you implement only additional parameters for programs detected by
> > configure and then run some kind of execvp call rather than the normal
> > system call, no additional program can be run that way.
>
> Since execvp is platform-dependant (onl
On 09/05/2009 17:35, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
if you implement only additional parameters for programs detected by
configure and then run some kind of execvp call rather than the normal
system call, no additional program can be run that way.
Since execvp is platfo
Pavel Sanda wrote:
> if you implement only additional parameters for programs detected by
> configure and then run some kind of execvp call rather than the normal
> system call, no additional program can be run that way.
Since execvp is platform-dependant (only UNIX), QProcess strikes me like the
Isn't that what I was suggesting a few days ago? Well, not quite,
since I was suggesting we just put them all on the menu so that
they're all there to be chosen from, on an ad hoc basis, rather than
making the user go into the preferences or settings or something to
change them. JMarc, what
Jürgen Spitzmüller wrote:
Jean-Marc Lasgouttes wrote:
Here comes the first step. This implements the possibility to record all
available programs of a sort in alternative RCs.
I would love to have that for converters, so that configure.py
configures all available converters/viewers,
Jean-Marc Lasgouttes wrote:
>> Here comes the first step. This implements the possibility to record all
>> available programs of a sort in alternative RCs.
>
> I would love to have that for converters, so that configure.py
> configures all available converters/viewers, not only the first one that
Jürgen Spitzmüller writes:
> Here comes the first step. This implements the possibility to record all
> available programs of a sort in alternative RCs.
I would love to have that for converters, so that configure.py
configures all available converters/viewers, not only the first one that
fits.
Pavel Sanda wrote:
> if you implement only additional parameters for programs detected by
> configure and then run some kind of execvp call rather than the normal
> system call, no additional program can be run that way.
Thanks.
Here comes the first step. This implements the possibility to recor
Jürgen Spitzmüller wrote:
> Of course, we could just issue a (toggleable) warning if a per-document app
> is
> about to be launched, but is that enough?
users tend to click without checking whats going on...
if you implement only additional parameters for programs detected by configure
and then
Part of my attempt to make some settings customizable on a per-document basis
is the plan to allow this also for tools such as bibtex and the index
processor. There are many use cases for this:
* you might want to use a different program for a specific document (bibtex8
or biber for documents u
18 matches
Mail list logo
