It looks good. Do we really want to redirect stderr too?
This is for a complete report of the configure process, although we do
not usually expect configure to fail.
Please apply it to branch and trunk.
Done.
Bo
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> The following would work. Do you want such a patch?
>> Yes, I think so.
>>
Bo> Attched. Ok also for 1.4.x?
It looks good. Do we really want to redirect stderr too?
Please apply it to branch and trunk.
JMarc
Bo> The following would work. Do you want such a patch?
Yes, I think so.
Attched. Ok also for 1.4.x?
Bo
configure.log.diff
Description: Binary data
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> BTW, would it be possible to modifiy configure.py to make a copy of
>> its output in a file named config.log? This would be handy to be
>> able to check later how detection went.
Bo> The following would work. Do you want such a patch?
Yes, I t
You mean that we cannot redirect stdout/err globally to a file?
Frankly I do not know. The only method i know to get stdin/out for a
no-console windows program is createConsole which will display the
ugly console even if we can later on hide or redirect stdin/out. The
only perfect way to avoid c
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> This energy would be better used by removing the console and
>> redirecting the output in some file.
Bo> I am not 100% sure but it seems to me that even if lyx itself can
Bo> get rid of the console window, many of the scripts lyx calls need
Bo>
This energy would be better used by removing the console and
redirecting the output in some file.
I am not 100% sure but it seems to me that even if lyx itself can get
rid of the console window, many of the scripts lyx calls need it. A
console window will be created whenever such a script is ca
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I say, go for it. The LyX executable compiled in the main tree
Angus> would become lyxc.exe, a console app, and your thin WinGUI
Angus> wrapper would be lyx.exe. If our users need to debug a problem,
Angus> they just invoke lyxc.exe
Please test. It works for me.
The program is now a little bit hard to follow (i am so used to
string/vector etc) but it works under winxp/msvc. I just applied it.
Thanks.
Bo
Seems to work for me in the sense that there is only a small blinking
visible, if at all. The advantage would be that the user can can change
Lyx.bat easily.
This is also a good idea but does not work now since I have removed
the console-hiding code from os_win32.C. Using your trick will result
On Wed, Jul 26, 2006 at 11:18:52AM -0500, Bo Peng wrote:
> > We could arrange things such that the program looks at its name and if
> > it isn't called lyx.exe it behaves exactly as it does now, otherwise,
> > after parsing the env vars, it prefixes the remaining parameters on the
> > command line
Hi,
a quite primitive work around is to insert /MIN in the Lyx.bat file,
which would read now
SET LC_ALL=en_EN
SET AIK_DATA_DIR=C:\Program Files\LyX14\aiksaurus
start "LyX" /MIN "C:\Program Files\LyX14\bin\lyx.exe" %*
Seems to work for me in the sense that there is only a small blinking
visible
We could arrange things such that the program looks at its name and if
it isn't called lyx.exe it behaves exactly as it does now, otherwise,
after parsing the env vars, it prefixes the remaining parameters on the
command line with "cmd /c lyxc.exe".
It becomes too magical then. I would prefer ei
On Wed, Jul 26, 2006 at 10:29:28AM -0500, Bo Peng wrote:
> > Agreed. I think the wrapper should be named lyx.exe and should internally
> > call the real lyx named lyxc.exe. The wrapper should examine the command
> > line for options of the form /VAR=val in order to set environment variables
> > as
Bo Peng <[EMAIL PROTECTED]> writes:
> I agree with something like
> lyx.exe /var=val /var1=val1 file1.lyx file2.lyx
lyx.exe /var=val /var1=val1 -dbg=4 --geometry="10x10+10-10" file1.lyx file2.lyx
Yuck! LyX itself uses "-" and "--" to denote options. So should the wrapper.
Other than that, I'm in
Agreed. I think the wrapper should be named lyx.exe and should internally
call the real lyx named lyxc.exe. The wrapper should examine the command
line for options of the form /VAR=val in order to set environment variables
as appropriate and should pass everything else onto lyxc.exe.
I agree wit
On Wed, Jul 26, 2006 at 02:07:41PM +, Angus Leeming wrote:
> Enrico Forestieri <[EMAIL PROTECTED]> writes:
> > > Further, if you're correct and /foo/bar causes problems, then why not
> > > transform such paths to \foo\bar form before spawning lyx.exe?
>
> > This is what happens on win2k. Acc
So why not allow the nice, friendly interface to wrapper.exe, but internally
pass in "cmd.exe" to CreateProcess?
I actually though about this, but I guess Uwe/Joost may want to do
wrapper.exe lyx.bat
which is the easiest way to fix our current installer. Anyway, I guess
adding (internally) cmd
Enrico Forestieri <[EMAIL PROTECTED]> writes:
> > Further, if you're correct and /foo/bar causes problems, then why not
> > transform such paths to \foo\bar form before spawning lyx.exe?
> This is what happens on win2k. According to Bo, lyx.exe is hidden on winxp
> when use either '/' or '\' as a
On Wed, Jul 26, 2006 at 11:50:52AM +, Angus Leeming wrote:
> Enrico Forestieri <[EMAIL PROTECTED]> writes:
> > I am using Win2k sp4. I am surprised that this makes a difference.
> > However, I notice that if I use forward slashes in the path to lyx.exe,
> > it indeed starts hidden and I have t
Enrico Forestieri <[EMAIL PROTECTED]> writes:
> I am using Win2k sp4. I am surprised that this makes a difference.
> However, I notice that if I use forward slashes in the path to lyx.exe,
> it indeed starts hidden and I have to kill it from Task Manager...
> Windows really drives me mad...
I susp
On Tue, Jul 25, 2006 at 11:02:02AM -0500, Bo Peng wrote:
> > It works for me. Using hidecmd from a shortcut to start LyX I have
> > no flashing cmd window and LyX starts normally.
>
> I tried your version, mine, and the merged one. All of them hide lyx.
> I use winxp sp2, what do you use? Anyway,
On 7/25/06, Angus Leeming <[EMAIL PROTECTED]> wrote:
Bo Peng <[EMAIL PROTECTED]> writes:
> BTW, I am forced to link to libcmt.lib and my version of hidecmd.exe
> is 6k, comparable to Enrico's mingw version. The orginal program size
> is 1.5k.
Given that all this thing does is launch the real lyx
Bo Peng <[EMAIL PROTECTED]> writes:
> BTW, I am forced to link to libcmt.lib and my version of hidecmd.exe
> is 6k, comparable to Enrico's mingw version. The orginal program size
> is 1.5k.
Given that all this thing does is launch the real lyx once, I don't think you
need worry about code size. I
I say, go for it. The LyX executable compiled in the main tree would become
lyxc.exe, a console app, and your thin WinGUI wrapper would be lyx.exe. If our
users need to debug a problem, they just invoke lyxc.exe from the command line.
The patches have been submitted. I will leave to the install
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> | BTW, would you welcome a patch to remove the hide console trick in
> | os_win32.C? The trick is ugly (personal opinion) and prevents us from
> | viewing stdout during debugging.
> I do not really have a view on that You windows people have to
>
"Bo Peng" <[EMAIL PROTECTED]> writes:
| >
| > I am fine with either.
|
| Then I will put it under development/Win32. I hope that I can get the
| svn properties right this time.
|
| BTW, would you welcome a patch to remove the hide console trick in
| os_win32.C? The trick is ugly (personal opinio
I am fine with either.
Then I will put it under development/Win32. I hope that I can get the
svn properties right this time.
BTW, would you welcome a patch to remove the hide console trick in
os_win32.C? The trick is ugly (personal opinion) and prevents us from
viewing stdout during debugging.
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > Where do you plan to put a tool like this?
|
| There is a cygwin equivalence under development/Win32 so I plan to put
| this there as well. If Joost likes it and want to take it over, he can
| put this along with the windows installer.
|
| I am fine with
Where do you plan to put a tool like this?
There is a cygwin equivalence under development/Win32 so I plan to put
this there as well. If Joost likes it and want to take it over, he can
put this along with the windows installer.
I am fine with both options.
Bo
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > It works for me. Using hidecmd from a shortcut to start LyX I have
| > no flashing cmd window and LyX starts normally.
|
| I tried your version, mine, and the merged one. All of them hide lyx.
| I use winxp sp2, what do you use? Anyway, I guess it is time
It works for me. Using hidecmd from a shortcut to start LyX I have
no flashing cmd window and LyX starts normally.
I tried your version, mine, and the merged one. All of them hide lyx.
I use winxp sp2, what do you use? Anyway, I guess it is time to hand
this to Uwe/Joost and let them try this wi
This would make sense only if msvc produces a very big executable.
After stripping it, the executable produced by gcc is about 5Kb and
I would be surprised if msvc does much worse than that.
The author's version is less than 1k I have not reproduced
(checked) that by myself though.
Bo
On Tue, Jul 25, 2006 at 12:11:45PM +, Angus Leeming wrote:
> Bo Peng <[EMAIL PROTECTED]> writes:
> // The original author used some tricks to reduce executable
> // size. They are removed to make the program compatible to
> // mingw/gcc.
>
> Rather than comment these #pragmas out, why not pro
Bo Peng <[EMAIL PROTECTED]> writes:
// The original author used some tricks to reduce executable
// size. They are removed to make the program compatible to
// mingw/gcc.
Rather than comment these #pragmas out, why not protect them with a #ifdef
MSVC block?
Angus
// do not link to default libra
On Mon, Jul 24, 2006 at 09:49:05PM -0500, Bo Peng wrote:
> > Nope, I am using it from a shortcut. You have to specify the full path
> > to lyx.exe 'hidecmd C:\Programs\LyX14\bin\lyx.exe'.
>
> Enrico,
>
> I have tried again and studied the source. What you described seems to
> be wrong. hidecmd.
Nope, I am using it from a shortcut. You have to specify the full path
to lyx.exe 'hidecmd C:\Programs\LyX14\bin\lyx.exe'.
Enrico,
I have tried again and studied the source. What you described seems to
be wrong. hidecmd.exe *hides* whatever command it tries to execute so
"hidecmd.exe lyx.exe"
On Sun, Jul 23, 2006 at 01:18:38PM -0500, Bo Peng wrote:
> > Yes, I tried. It works perfectly. Hidecmd simply hides the cmd window
> > that otherwise would open when launching lyx.exe.
>
> I guess you are starting hidecmd in a command window. What you need to
> test is creating a desktop shortcut
Yes, I tried. It works perfectly. Hidecmd simply hides the cmd window
that otherwise would open when launching lyx.exe.
I guess you are starting hidecmd in a command window. What you need to
test is creating a desktop shortcut, with commands like 'hidecmd
lyx.exe'.
Bo
On Sun, Jul 23, 2006 at 09:15:33AM -0500, Bo Peng wrote:
> > We need to set some environment variables. Please have a look at the
> > attached program modified from the same source as yours.
>
> This looks good, we can replace the lyx.bat file with this shortcut.
>
> > hidecmd /LC_ALL=it_IT /AIK
We need to set some environment variables. Please have a look at the
attached program modified from the same source as yours.
This looks good, we can replace the lyx.bat file with this shortcut.
hidecmd /LC_ALL=it_IT /AIK_DATA_DIR="C:\Programmi\LyX14\aiksaurus" lyx.exe
I don't see the need to
On Sun, Jul 23, 2006 at 09:29:28AM +0200, Enrico Forestieri wrote:
> On Sat, Jul 22, 2006 at 10:23:55PM -0500, Bo Peng wrote:
>
> > Dear list,
> >
> > Using this small utility, we can hide the console window of lyx by
> > starting lyx with
> >
> > runWithHiddenConsole cmd.exe /c lyx.exe
> >
On Sat, Jul 22, 2006 at 10:23:55PM -0500, Bo Peng wrote:
> Dear list,
>
> Using this small utility, we can hide the console window of lyx by
> starting lyx with
>
> runWithHiddenConsole cmd.exe /c lyx.exe
>
> I suggest that we remove the hide console code in os_win32.c if this
> program is us
43 matches
Mail list logo