Michael Schmitt wrote:
The child process fixes have not been committed to LyX 1.3.6cvs yet. I
still have to apply a subset of your "win32_10jan05.diff" patch
Indeed. And having applied this subset, you find that LyX blocks until
your
graphics images are converted and loaded onto the screen, no?
The child process fixes have not been committed to LyX 1.3.6cvs yet. I
still have to apply a subset of your "win32_10jan05.diff" patch
Indeed. And having applied this subset, you find that LyX blocks until
your
graphics images are converted and loaded onto the screen, no?
Who cares? If we don't te
Michael Schmitt wrote:
>> Incidentally, apart from the fact that the graphics conversion (for the
>> screen) blocks the execution of LyX, I think that LyX 1.3.x/Win should
>> now be a fully-functioning equivalent of LyX/*nix.
>
> The child process fixes have not been committed to LyX 1.3.6cvs yet.
Incidentally, apart from the fact that the graphics conversion (for the
screen) blocks the execution of LyX, I think that LyX 1.3.x/Win should now
be a fully-functioning equivalent of LyX/*nix.
The child process fixes have not been committed to LyX 1.3.6cvs yet. I still
have to apply a subset of
Michael Schmitt wrote:
Dear Angus,
there is a small bug in os_win32.C (tested with LyX 1.3.6cvs):
Function "cygwin_path_fix(bool)" must be part of namespace "os". Please
change the signature to "os::cygwin_path_fix(bool)".
Thanks, Michael. I've just spotted th
Dear Angus,
there is a small bug in os_win32.C (tested with LyX 1.3.6cvs):
Function "cygwin_path_fix(bool)" must be part of namespace "os". Please
change the signature to "os::cygwin_path_fix(bool)".
Thanks, Michael
