Re: LyX on Windows
Hi, I managed to checkout qt3 win32 free and lyx-devel. I even managed to compile qt-3, although I ran out of disk space, and what not. Now, I'm starting to build a VS.NET 7.1 project file for LyX, but I need all the generated files from configure on Windows from one of you guys, since I refuse to install cygwin or mingw. For starters, could someone hand me a config.h file? Also, if someone could provide a rough list of which source files (i.e. which directories) needs to be compiled into the LyX proper in the Qt edition, that would be helpfulp. Thanks, Asger
Re: LyX on Windows
Asger Ottar Alstrup wrote: > I managed to checkout qt3 win32 free and lyx-devel. Note that I've only tried to get BRANCH_1_3_X to compile. > I even managed to > compile qt-3, although I ran out of disk space, and what not. > > Now, I'm starting to build a VS.NET 7.1 project file for LyX, but I need > all the generated files from configure on Windows from one of you guys, > since I refuse to install cygwin or mingw. When it comes to *running* lyx you'll still need a decent shell and associated utilities to run the lib/configure scipt. > For starters, could someone hand me a config.h file? Mine are attached, both for 1.3.x and for 1.4.x. > Also, if someone could provide a rough list of which source files (i.e. > which directories) needs to be compiled into the LyX proper in the Qt > edition, that would be helpfulp. You need the qt3.3.3.dll (or some such name). Is that not the end result of compiling the src/kernel directories? You'll also need the uic and moc executables. -- Angus config_13x.h.bz2 Description: BZip2 compressed data config_14x.h.bz2 Description: BZip2 compressed data
Re: LyX on Windows
Angus Leeming wrote: Note that I've only tried to get BRANCH_1_3_X to compile. OK, I'm working on the main branch. When it comes to *running* lyx you'll still need a decent shell and associated utilities to run the lib/configure scipt. That is something to address then for a native Windows port to work out. I'd like to produce a native LyX binary with as few unix dependencies as possible. Further out, I'd even like to kick out LaTeX, and put some other backend in instead to reduce the footprint. Mine are attached, both for 1.3.x and for 1.4.x. Thanks, that gets me down to about 1500 remaining errors and warnings ;-) You need the qt3.3.3.dll (or some such name). Is that not the end result of compiling the src/kernel directories? There is no src/kernel directory, but I have a qt-mt3.dll from the Qt compile. > You'll also need the uic and moc executables. I have those as part of the Qt compile. What is the compilation procedure for those Qt .ui files? I get a bunch of errors like: QERTDialog.C c:\lyx\lyx-devel\src\frontends\qt2\QERTDialog.h(15) : fatal error C1083: Cannot open include file: 'ui/QERTDialogBase.h': No such file or directory so I guess those files are generated by some Qt utility. My plan is this: - get everything to compile. - get everything to link. - get it to start-up (without crash). - get it to run without all those unix dependencies. The main barrier for me is disk space... I keep running out, and since it's a laptop, it's a bit problematic for me to add more space. I'll have to get an external firewire or usb-2 disc I suppose. Regards, Asger
Re: LyX on Windows
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: | I have those as part of the Qt compile. > | What is the compilation procedure for those Qt .ui files? That is in the makefiles... If you want to do this without the use of automake/autoconf: Good Luck. But please do not clutter the directories with .proj files. -- Lgb
Re: LyX on Windows
Asger Ottar Alstrup wrote: > That is something to address then for a native Windows port to work out. > I'd like to produce a native LyX binary with as few unix dependencies as > possible. I think that this is a very plausible goal. The only big task will be to rewrite lib/configure as a python script. > Further out, I'd even like to kick out LaTeX, and put some > other backend in instead to reduce the footprint. Note that I'm running lyx 1.3.x on windows without any LaTeX installation at all. I can't generate printable output but I can edit the .lyx files. >> You need the qt3.3.3.dll (or some such name). Is that not the end result >> of compiling the src/kernel directories? > > There is no src/kernel directory, but I have a qt-mt3.dll from the Qt > compile. I thought you were talking about which bits of the Qt source were needed by LyX? > What is the compilation procedure for those Qt .ui files? See /src/frontend/qt2/ui/Makefile.am. It's not very hard to decipher ;-) -- Angus
Re: LyX on Windows
Lars Gullik Bjønnes wrote: | What is the compilation procedure for those Qt .ui files? That is in the makefiles... Does anybody know the exact command line I need to use? If you want to do this without the use of automake/autoconf: Good Luck. But please do not clutter the directories with .proj files. I am making one .sln file, and one .vcproj file for the entire tree. Regards, Asger
Re: LyX on Windows
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> | What is the compilation procedure for those Qt .ui files? >> That is in the makefiles... > | Does anybody know the exact command line I need to use? > >> If you want to do this without the use of automake/autoconf: Good >> Luck. But please do not clutter the directories with .proj files. > | I am making one .sln file, and one .vcproj file for the entire tree. > | Regards, | Asger > UICFLAGS=-tr qt_ %.h: %.ui $(UIC) $(UICFLAGS) $< -o $@ %.C: %.h %.ui $(PCH_FILE) $(UIC) $(UICFLAGS) -impl `echo $^ | sed 's/pch.h.gch//'` -o $@ the .h file: uic -tr qt_ foo.ui -o foo.h the .C file: uic -tr qt_ foo.ui -impl foo.h foo.ui -o foo.C -- Lgb
Re: LyX on Windows
Asger Ottar Alstrup wrote: > My plan is this: > - get everything to compile. > - get everything to link. > - get it to start-up (without crash). > - get it to run without all those unix dependencies. My immediate targets are * to address the question that started this thread --- do you have any insights you'd care to share? * the signal handling code in lyx_main.C. I'm aware that the non-existence of SIGHUP under Windows isn't an issue. I also understand from Microsoft's "UNIX Application Migration Guide" http://msdn.microsoft.com/library/en-us/dnucmg/html/UCMGch09.asp?frame=true#ucmgch09_topic3 Equivalent URL: http://tinyurl.com/3pbpp that Windows' signal implentation supports all of the signals that we're interested in: = Table 3. Windows signals SIGFPEFloating-point error SIGINTCTRL+C signal SIGSEGV Illegal storage access SIGTERM Termination request Note When a Ctrl+C interrupt occurs, Win32 operating systems generate a new thread to handle the interrupt. This can cause a single-thread application, such as one ported from UNIX, to become multithreaded, potentially resulting in unexpected behavior. = So, we should probably use Windows Messages instead of SIGINT because LyX definitely isn't a multithreaded beast. Again, have you any thoughts on this? -- Angus
Re: LyX on Windows
Hi Angus,
The irritating thing with Windows is that all stdout messages get lost
somewhere when using the GUI subsystem. You would have to add additional
code to handle all debugging messages. Now that isn´t that hard to do, but
another issue was that some shell script stopped working when linking to the
gui subsystem. I cannot remember what worked and what didn´t. Maybe the
mingw runtime does a better job, but you´ll have to try that out.
Anyway, at that time I´ve looked around, but there didn´t seem to be a more
elegant solution. The console closing code is not that sophisticated, so
that could be improved.
BTW The WinMain stuff get´s added by qtmain automatically.
Ruurd
"Angus Leeming" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Good evening, Ruurd.
>
> I wonder if you could help out a Windows novice --- me?
> My question concerns the way that Windows treats LyX --- as
> a Windows GUI app or as a console one. At the moment, Windows
> believes that LyX is a console app because it has a "main"
> function rather than a "WinMain".
>
> You've added code in os_win32.C's init function to close
> down the console window that Windows helpfully displays
> for us:
>
> void os::init(int /* argc */, char * argv[])
> {
> #ifdef _WIN32
> // Close the console when run (probably)
> // not run from command prompt
> char WindowTitle[1024];
> HWND hwndFound;
> GetConsoleTitle(WindowTitle,1024);
> if ((strcmp(WindowTitle, argv[0]) == 0) ||
> (strcmp(WindowTitle,"LyX") == 0)) {
> // format a "unique" newWindowTitle
> wsprintf(WindowTitle,"%d/%d",
> GetTickCount(),
> GetCurrentProcessId());
> // change current window title
> SetConsoleTitle(WindowTitle);
> // ensure window title has been updated
> Sleep(40);
> // look for newWindowTitle
> hwndFound=FindWindow(NULL, WindowTitle);
> // If found, hide it
> if ( hwndFound != NULL)
> ShowWindow( hwndFound, SW_HIDE);
> }
> #endif
> }
>
>
> Would it not be more elegant to tell Windows that LyX
> is actually a GUI-based app by giving it a WinMain?
>
> The code below compiles fine for me with
> $ g++ -mwindows -o trial trial.C
>
> #if defined (_WIN32)
> # define WIN32_LEAN_AND_MEAN
> # include // for __argc, __argv
> # include // for WinMain
> #endif
>
>
> #if defined (_WIN32)
> int mymain(int argc, char * argv[])
> #else
> int main(int argc, char * argv[])
> #endif
> {
> // LyX's code, unchanged, goes here.
> Sleep(5000);
> return 0;
> }
>
>
> // This will require the "-mwindows" flag when linking with
> // gcc under MinGW.
> // For MSVC, use "/subsystem:windows".
> #if defined (_WIN32)
> int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
> {
> std::cout << "WinMain" << std::endl;
> return mymain(__argc, __argv);
> }
> #endif
>
> Regards,
> Angus
>
Re: LyX on Windows
Asger, you might want to look into am2msdev ftp://ftp.slac.stanford.edu/users/pfkeb/automake/. This tool will at least provide you with a skeleton. And, I believe the source even includes a project file, so no scary mingw/cygwin tools. There also seems to be an options to add visual studio directives to automake files, that get ignored by the normal autotools. But..I´ve tried what you are trying right now, but became very frustated with this approach;-) Ruurd "Asger Ottar Alstrup" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi, > > I managed to checkout qt3 win32 free and lyx-devel. I even managed to > compile qt-3, although I ran out of disk space, and what not. > > Now, I'm starting to build a VS.NET 7.1 project file for LyX, but I need > all the generated files from configure on Windows from one of you guys, > since I refuse to install cygwin or mingw. > > For starters, could someone hand me a config.h file? > > Also, if someone could provide a rough list of which source files (i.e. > which directories) needs to be compiled into the LyX proper in the Qt > edition, that would be helpfulp. > > Thanks, > Asger >
Re: LyX on Windows
Ruurd Reitsma wrote:
> Hi Angus,
>
> The irritating thing with Windows is that all stdout messages get lost
> somewhere when using the GUI subsystem. You would have to add additional
> code to handle all debugging messages. Now that isn´t that hard to do,
> but another issue was that some shell script stopped working when linking
> to the gui subsystem. I cannot remember what worked and what didn´t.
> Maybe the mingw runtime does a better job, but you´ll have to try that
> out.
>
> Anyway, at that time I´ve looked around, but there didn´t seem to be a
> more elegant solution. The console closing code is not that
> sophisticated, so that could be improved.
>
> BTW The WinMain stuff get´s added by qtmain automatically.
Reading this thread
http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html
A Windows application does not have any stdout/stderr by default, all
output vanishes without a trace for you.But if you want to, you can create
a console with AllocConsole() and attach that to stdout/stderr ...
Add following lines into main :
#ifdef WIN32
AllocConsole();
freopen("conin$", "r", stdin);
freopen("conout$", "w", stdout);
freopen("conout$", "w", stderr);
#endif
That suggests that the console could be added when lyxerr is invoked.
Anyway, I think that I'll just add your code as-is for now with some
commentary describing the alternative.
--
Angus
Re: LyX on Windows
"Angus Leeming" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Reading this thread
> http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html
>
> A Windows application does not have any stdout/stderr by default, all
> output vanishes without a trace for you.But if you want to, you can create
> a console with AllocConsole() and attach that to stdout/stderr ...
>
> Add following lines into main :
> #ifdef WIN32
> AllocConsole();
> freopen("conin$", "r", stdin);
> freopen("conout$", "w", stdout);
> freopen("conout$", "w", stderr);
> #endif
>
Yep, tried this too. But then it turned out that some shell scripts failed,
for mysterious reasons...
Ruurd
Re: LyX on Windows
Ruurd Reitsma wrote:
> "Angus Leeming" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>> Reading this thread
>> http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html
>>
>> A Windows application does not have any stdout/stderr by default, all
>> output vanishes without a trace for you.But if you want to, you can
>> create a console with AllocConsole() and attach that to stdout/stderr
>> ...
>>
>> Add following lines into main :
>> #ifdef WIN32
>> AllocConsole();
>> freopen("conin$", "r", stdin);
>> freopen("conout$", "w", stdout);
>> freopen("conout$", "w", stderr);
>> #endif
>>
>
> Yep, tried this too. But then it turned out that some shell scripts
> failed, for mysterious reasons...
So, as said. I'll do it your way and add some notes about why. This is
something that can easily be revisited at a later date.
--
Angus
Re: LyX on Windows
Angus Leeming <[EMAIL PROTECTED]> writes:
| Ruurd Reitsma wrote:
>> Hi Angus,
>>
>> The irritating thing with Windows is that all stdout messages get lost
>> somewhere when using the GUI subsystem. You would have to add additional
>> code to handle all debugging messages. Now that isn´t that hard to do,
>> but another issue was that some shell script stopped working when linking
>> to the gui subsystem. I cannot remember what worked and what didn´t.
>> Maybe the mingw runtime does a better job, but you´ll have to try that
>> out.
>>
>> Anyway, at that time I´ve looked around, but there didn´t seem to be a
>> more elegant solution. The console closing code is not that
>> sophisticated, so that could be improved.
>>
>> BTW The WinMain stuff get´s added by qtmain automatically.
>
| Reading this thread
| http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html
>
| A Windows application does not have any stdout/stderr by default, all
| output vanishes without a trace for you.But if you want to, you can create
| a console with AllocConsole() and attach that to stdout/stderr ...
>
| Add following lines into main :
| #ifdef WIN32
| AllocConsole();
| freopen("conin$", "r", stdin);
| freopen("conout$", "w", stdout);
| freopen("conout$", "w", stderr);
| #endif
>
| That suggests that the console could be added when lyxerr is invoked.
>
| Anyway, I think that I'll just add your code as-is for now with some
| commentary describing the alternative.
I feel we are beginning on a slippery slope now... ok to support
windows if only minimal changes are needed... but now we see more and
more changes needed to support this.
I am not sure that I am really happy about this "progress"
--
Lgb
Re: LyX on Windows
Lars Gullik Bjønnes wrote: > I feel we are beginning on a slippery slope now... ok to support > windows if only minimal changes are needed... but now we see more and > more changes needed to support this. > > I am not sure that I am really happy about this "progress" Let me try and reassure you then. If you look at the code base, you'll find minimal evidence of any pollution. Why don you think I've taken a month to gradually merge Ruurd's changes into the repository rather than just commit the thing in its original state? $ egrep -r '_WIN32|WINDOWS' src shows that the only files containing even a sniff of Windows-specific stuff are: src/config.h.in src/support/filename.C src/support/os.C src/support/os_win32.C src/support/package.C.in That doesn't look too terrible, does it? The same is true of all the changes yet to come. Everything can be encapsulated so that the code base suffers minimally. So, what else needs to be done before Ruurd's patch can be declared as fully-merged? 1. This code we've been discussing about Windows notion of a console or a gui app. 2. The signal-handling code needs to be considered carefully as we have a reputation to consider; LyX doesn't eat your data ;-) I plan to write some little test codes to try out the MinGW implementation of these. See also my message a little later in this thread http://article.gmane.org/gmane.editors.lyx.devel:40725 3. The child process code. My general plan is to first refactor the existing code a little so that we present a common interface to the rest of LyX. Again, that's not slippery slope territory. Thereafter, we will need some Windows specific code, but that will be hidden away behind this interface. At that point, we can say that all is done. Fin. Finito. Ferdig. -- Angus
Re: LyX on Windows
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> I feel we are beginning on a slippery slope now... ok to support >> windows if only minimal changes are needed... but now we see more and >> more changes needed to support this. >> >> I am not sure that I am really happy about this "progress" > | Let me try and reassure you then. If you look at the code base, you'll | find minimal evidence of any pollution. Why don you think I've taken a | month to gradually merge Ruurd's changes into the repository rather than | just commit the thing in its original state? So far it has been stuff that makes LyX more portable. A good thing. But now we are also beginning to much with the build system. As much as I'd like Asger to work on LyX again I am not sure these changes (depends completely how they evolve) are worth it in the long run. I just wanted to "flag" my growing concerns. -- Lgb
Re: LyX on Windows
Lars Gullik Bjønnes wrote: I just wanted to "flag" my growing concerns. Frankly, I consider this FUD. Complain when you see something you disagree with. Do not complain in advance about what you fear might happen. Regards, Asger
Re: LyX on Windows
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> I just wanted to "flag" my growing concerns. > | Frankly, I consider this FUD. Complain when you see something you | disagree with. Do not complain in advance about what you fear might | happen. Well then I am full of FUD, and as we have seen if you don't speak up before something happens... after the fact it is too late... And (also) frankly I am not at all alleviated by having my concerns called FUD. My fuddy feellings just increased instead. One thing I do disagree with is having several ways of building LyX. -- Lgb
Re: LyX on Windows
Lars Gullik Bjønnes wrote: >>> I feel we are beginning on a slippery slope now... ok to support >>> windows if only minimal changes are needed... but now we see more and >>> more changes needed to support this. >>> >>> I am not sure that I am really happy about this "progress" >> > | Let me try and reassure you then. If you look at the code base, you'll > | find minimal evidence of any pollution. Why don you think I've taken a > | month to gradually merge Ruurd's changes into the repository rather > | than just commit the thing in its original state? > > So far it has been stuff that makes LyX more portable. A good thing. > But now we are also beginning to much with the build system. As I see it, you do not need to worry about this either. Asger is not proposing to muck with the existing build system at all. He's proposing to add an entirely separate one. Moreover, he appears to be talking about adding a maximum of one or two files to the root directory of the repository. Given that the reposititory currently contains 4309 files, I don't think that is any problem at all ;-) > As much as I'd like Asger to work on LyX again I am not sure these > changes (depends completely how they evolve) are worth it in the long > run. My view? We've gone so far to make this bloody thing 'portable'. We should go the extra mile to prove that it actually is portable and not just 'portable'. Otherwise, who are we trying to kid? > I just wanted to "flag" my growing concerns. LOL. Don't worry, Lars, I'm on your side here. (Ok, ok, that might well be something you were worried might happen ;-) -- Angus
Re: LyX on Windows
Angus Leeming wrote: As I see it, you do not need to worry about this either. Angus, even though it's not Friday yet, I think I am going to have to curse you up and down now until you can't see what is up and down anymore. It's for your own good. You see, Lars and I are just starting to heat up to get a real good flame-fest going that might last all up to Friday. It would be like the good old days! But then you come along talking nice soft words and putting all this oil on the waters. Jean-Marc said it: you're a real diplomat, but sometimes a party-spoiler as well. In this case, diplomacy is not what the doctor ordered: On the LyX-devel list, you have to be nice to the *new-comers*. But all the others, you have to scorn and give a hell of a time starting exactly Monday. This state of affairs builds up over the week come Friday, where everybody makes up, and have a beer. That's just the way it is, and the way it has always been. It's like heaven and hell. You can't have one without the other. So, with that basic lesson in LyX manners out of the way, will you let us resume the flame-fest as common courtesy calls for? Cheers, Asger
Re: LyX on Windows
Asger Ottar Alstrup wrote: > So, with that basic lesson in LyX manners out of the way, will you let > us resume the flame-fest as common courtesy calls for? Sure, you wanker. Happy now? -- Angus
Re: LyX on Windows
Lars Gullik Bjønnes wrote: Well then I am full of FUD, and as we have seen if you don't speak up before something happens... after the fact it is too late... Tell you what: This wanker is going to continue commiting things behind your back that I consider obvious monotoneous progress until you can find an example which you disagree with. And at that point, I guess you have to pull the plug and steal my karma! So, I'll be stretching the obviously correct rule to the limit, but I'll not cross it too much. And (also) frankly I am not at all alleviated by having my concerns called FUD. My fuddy feellings just increased instead. He he, I will keep the pressure up, so you better stay alert. One thing I do disagree with is having several ways of building LyX. So far, you should not loose sleep. I still have 275 errors and 399 warnings to combat. Regards, Asger
Re: LyX on Windows
Angus Leeming wrote: > Asger Ottar Alstrup wrote: >> So, with that basic lesson in LyX manners out of the way, will you let >> us resume the flame-fest as common courtesy calls for? > > Sure, you wanker. > Happy now? Incidentally, has an experienced Windows hand like yourself not got any suggestions for what I should do to handle SIGINT on Windows? I really don't think that we should use the existing code unchanged and define a signal handler for it if Windows is going to spawn a new thread to handle the Ctrl+C interupt. See my mail describing the problem elsewhere in this thread. LyX ain't in any fit state to be multi-threaded just yet and I've never written any Windows Messages code before... -- Angus
Re: LyX on Windows
> "Asger" == Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: Asger> That's just the way it is, and the way it has always been. It's Asger> like heaven and hell. You can't have one without the other. Sure. So you brought some hell for dinner, and you are surprised some other guest provides the heaven? JMarc
Re: LyX on Windows
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> Well then I am full of FUD, and as we have seen if you don't speak up >> before something happens... after the fact it is too late... > | Tell you what: This wanker is going to continue commiting things | behind your back that I consider obvious monotoneous progress until | you can find an example which you disagree with. And at that point, I | guess you have to pull the plug and steal my karma! That is another thing I don't like. We have been fairly good lately at letting all the other know what we are doing and posting patches to the list. I am not saying that the boost stuff needed patches to be posted, but a heads-up would have been nice. | So, I'll be stretching the obviously correct rule to the limit, but | I'll not cross it too much. And if you don't post any patches¹ at all I will pull the plug. ¹ Or let us know what you are doing. -- Lgb
Re: LyX on Windows
Angus Leeming wrote: Incidentally, has an experienced Windows hand like yourself not got any suggestions for what I should do to handle SIGINT on Windows? I say, forget about it. I do not think Ctrl+C normally sends an interrupt for Windows applications. I think it only happens for console applications, or in extreme situations where some malicious process sends such a signal intentionally. I have some questions for you: The intl\ folder contains a gnu gettext library. However, I need some generated files like "libintl.h" and probably more before that compiles. Could I have a copy? In globbing.C, you include . This does not exist on Windows. What is this? In gzstream.C, we require zlib, but it does not seem we have any checks for that. In forkedcontr.h and forkedcall.h, we use the pid_t type, which does not exist on Windows. Any ideas? I guess, this is stuff for the os_win32.h header. In general, all that forking and signal stuff needs a reworking, but I guess that was on your plate. In FileInfo, we use a bunch of Unix specific things, like mode_t and all the permission constants R_OK, W_OK, X_OK and F_OK. Any ideas for those? Finally, I get a bunch of compile errors: QMathMatrixDialog.C c:\lyx\lyx-devel\src\frontends\qt2\QDialogView.h(113) : error C2440: 'return' : cannot convert from 'lyx::frontend::QMathDialog *' to 'QDialog *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xmemory(156) : while compiling class-template member function 'QDialog *lyx::frontend::QView::form(void) const' with [ GUIDialog=lyx::frontend::QMathDialog ] c:\lyx\lyx-devel\src\frontends\qt2\QDialogView.h(150) : see reference to class template instantiation 'lyx::frontend::QView' being compiled with [ GUIDialog=lyx::frontend::QMathDialog ] c:\lyx\lyx-devel\src\frontends\qt2\QMath.h(25) : see reference to class template instantiation 'lyx::frontend::QController' being compiled with [ Controller=lyx::frontend::ControlMath, Base=lyx::frontend::QView ] Any ideas for those? Incidentally, I'm at 411 errors and 180 warnings now. Thanks. Asger
Re: LyX on Windows
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
| Finally, I get a bunch of compile errors:
>
| QMathMatrixDialog.C
| c:\lyx\lyx-devel\src\frontends\qt2\QDialogView.h(113) : error C2440:
| 'return' : cannot convert from 'lyx::frontend::QMathDialog *' to
| 'QDialog *'
| Types pointed to are unrelated; conversion requires
| reinterpret_cast, C-style cast or function-style cast
Compiler bug.
Does your compiler allow:
class Base {
public:
virtual Base * clone();
};
class Derived : public Base {
public:
virtual Base * clone() {
return new Derived;
}
};
?? (what about if we add some template classes?)
--
Lgb
Re: LyX on Windows
Lars Gullik Bjønnes wrote:
Does your compiler allow:
class Base {
public:
virtual Base * clone();
};
class Derived : public Base {
public:
virtual Base * clone() {
return new Derived;
}
};
?? (what about if we add some template classes?)
I haven't tried, since I ran out of time.
For those that are interested, attached is an archive of my changes so
far. Apply the patch, put os_win32.h in src/support and the rest of the
new files in development/win32.
I'd like to commit the struct<->class, and->&& and #include fixes, since
those are uncontroversial and improve correctness for all platforms.
The rest of the changes are mostly quick hacks that allows me to
discover the problematic areas. Those parts of NOT intended to be committed.
I'll not have time to continue work on this until tomorrow.
Regards,
Asger
msvc.tar.bz2
Description: Binary data
Re: LyX on Windows
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: | I'd like to commit the struct<->class, and->&& and #include fixes, | since those are uncontroversial and improve correctness for all | platforms. all sub-standard platforms you mean? I'll have a look at the patch. -- Lgb
Re: LyX on Windows
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> Does your compiler allow:
>> class Base {
>> public:
>> virtual Base * clone();
>> };
>> class Derived : public Base {
>> public:
>> virtual Base * clone() {
>> return new Derived;
>> }
>> };
>> ?? (what about if we add some template classes?)
>
| I haven't tried, since I ran out of time.
>
| For those that are interested, attached is an archive of my changes so
| far. Apply the patch, put os_win32.h in src/support and the rest of
| the new files in development/win32.
>
| I'd like to commit the struct<->class, and->&& and #include fixes,
| since those are uncontroversial and improve correctness for all
| platforms.
Several of the struxtg<->class changes should be fixed by changing the
definition instead. We should reserve the "struct" for old-C POD style
structs.
The and -> && is a good change, but if it is required, then your
compiler is buggy.
the include changes might be good, would have been interesting to see
some of the errors.
The #warning wrapping is ok.
--
Lgb
Re: LyX on Windows
Asger Ottar Alstrup wrote: > Angus Leeming wrote: >> Incidentally, has an experienced Windows hand like yourself not got any >> suggestions for what I should do to handle SIGINT on Windows? > > I say, forget about it. I do not think Ctrl+C normally sends an > interrupt for Windows applications. I think it only happens for console > applications, or in extreme situations where some malicious process > sends such a signal intentionally. > > I have some questions for you: > > The intl\ folder contains a gnu gettext library. However, I need some > generated files like "libintl.h" and probably more before that compiles. > Could I have a copy? Certainly. Attached is intl.tar.gz which contains all the files that aren't .o or .a files: charset.alias libgnuintl.h libintl.h ref-add.sed ref-del.sed > In globbing.C, you include . This does not exist on Windows. > What is this? Globbing? `ls *.cpp` returns "foo.cpp bar.cpp". That's globbing. globbing.[Ch] are used only by the XForms frontend. You don't need them. > In gzstream.C, we require zlib, but it does not seem we have any checks > for that. That's one for Lars. > In forkedcontr.h and forkedcall.h, we use the pid_t type, which does not > exist on Windows. Any ideas? I guess, this is stuff for the os_win32.h > header. In general, all that forking and signal stuff needs a reworking, > but I guess that was on your plate. > > In FileInfo, we use a bunch of Unix specific things, like mode_t and all > the permission constants R_OK, W_OK, X_OK and F_OK. Any ideas for those? Sure. Attached is the kludge file that is needed to compile LyX 1.3.x on Windows with g++ 3.4 under MinGW/MinSYS. os_win32.h should help you out a bit. > Incidentally, I'm at 411 errors and 180 warnings now. Should keep you busy when you're not changing nappies ;-) -- Angus intl.tar.gz Description: GNU Zip compressed data Index: src/ispell.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ispell.C,v retrieving revision 1.5.2.5 diff -u -p -r1.5.2.5 ispell.C --- src/ispell.C 7 Dec 2004 10:48:23 - 1.5.2.5 +++ src/ispell.C 18 Jan 2005 12:45:30 - @@ -21,12 +21,20 @@ #include "support/forkedcall.h" #include "support/lstrings.h" +#ifdef _WIN32 +# include "support/os_win32.h" +#endif + // HP-UX 11.x doesn't have this header #ifdef HAVE_SYS_SELECT_H #include #endif #include +#ifdef HAVE_UNISTD_H +# include +#endif + #ifndef CXX_GLOBAL_CSTD using std::strcpy; using std::strlen; @@ -309,11 +317,15 @@ bool ISpell::select(bool & err_read) tv.tv_sec = 2; tv.tv_usec = 0; +#ifdef HAVE_SELECT retval = ::select(SELECT_TYPE_ARG1 (max(pipeout[0], pipeerr[0]) + 1), SELECT_TYPE_ARG234 (&infds), 0, 0, SELECT_TYPE_ARG5 (&tv)); +#else + retval = -1; +#endif // error if (retval <= 0) Index: src/lyx_cb.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_cb.C,v retrieving revision 1.190.2.3 diff -u -p -r1.190.2.3 lyx_cb.C --- src/lyx_cb.C 10 Jan 2005 19:17:24 - 1.190.2.3 +++ src/lyx_cb.C 18 Jan 2005 12:45:31 - @@ -37,6 +37,10 @@ #include "support/systemcall.h" #include "support/lstrings.h" +#ifdef _WIN32 +# include "support/os_win32.h" // fork() +#endif + #include "BoostFormat.h" #include Index: src/lyx_main.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_main.C,v retrieving revision 1.134.2.10 diff -u -p -r1.134.2.10 lyx_main.C --- src/lyx_main.C 13 Jan 2005 10:09:46 - 1.134.2.10 +++ src/lyx_main.C 18 Jan 2005 12:45:32 - @@ -36,6 +36,10 @@ #include "support/package.h" #include "support/path.h" +#ifdef _WIN32 +# include "support/os_win32.h" // SIGHUP +#endif + #include "BoostFormat.h" #include Index: src/lyxserver.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxserver.C,v retrieving revision 1.48.2.2 diff -u -p -r1.48.2.2 lyxserver.C --- src/lyxserver.C 10 Jan 2005 19:17:27 - 1.48.2.2 +++ src/lyxserver.C 18 Jan 2005 12:45:32 - @@ -49,6 +49,10 @@ #include "support/lyxlib.h" #include "frontends/lyx_gui.h" +#ifdef _WIN32 +# include "support/os_win32.h" // F_SETFL, O_NONBLOCK, fcntl +#endif + #ifdef __EMX__ #include #include Index: src/support/forkedcall.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/forkedcall.C,v retrieving revision 1.11.2.2 diff -u -p -r1.11.2.2 forkedcall.C --- src/support/forkedcall.C 7 Dec 2004 10:50:09 - 1.11.2.2 +++ src/support/forkedcall.C 18 Jan 2005 12:45:35 - @@ -30,6 +30,9 @@ #include "lyxlib.h" #include "filetools.h" #include "os.h" +#ifdef _WIN32 +#include "os_win32.h" +#endif #include "debug.h" #include "frontends/Timeout.h" @@ -37,7 +40,9 @@ #include #include -#include +#ifdef HAVE_SYS_WAIT_H +# incl
Re: LyX on Windows
Angus Leeming wrote: > Asger Ottar Alstrup wrote: >> Angus Leeming wrote: >>> Incidentally, has an experienced Windows hand like yourself not got any >>> suggestions for what I should do to handle SIGINT on Windows? >> >> I say, forget about it. I do not think Ctrl+C normally sends an >> interrupt for Windows applications. I think it only happens for console >> applications, or in extreme situations where some malicious process >> sends such a signal intentionally. I forgot to keep my diplomatic hat on and say "Thank you". Mea culpa. >> I have some questions for you: -- Angus
Re: LyX on Windows
Angus Leeming <[EMAIL PROTECTED]> writes:
| Asger Ottar Alstrup wrote:
>> In gzstream.C, we require zlib, but it does not seem we have any checks
>> for that.
| That's one for Lars.
AC_ARG_ENABLE(compression-support,
AC_HELP_STRING([--enable-compression-support]
,[Support for compressed files.]),[
case "${enableval}" in
yes) use_compression=true ;;
no) use_compression=false ;;
*) AC_MSG_ERROR(bad value ${enableval} for
--enable-compression-support)
;;
esac
],[use_compression=true])
if test $use_compression=true ; then
AC_CHECK_HEADERS(zlib.h, use_compression=true,
use_compression=false)
AC_CHECK_LIB(z, gzopen,[use_compression=true;LIBS="$LIBS
-lz"], use_comp
ression=false)
if test $use_compression = true ; then
AC_DEFINE(USE_COMRESSION, 1, [Define as 1 if you want
to support
compressed files.])
lyx_flags="$lyx_flags compression"
fi
fi
AM_CONDITIONAL(USE_COMPRESSION, test x$use_compression = xtrue)
AC_MSG_CHECKING([whether to support compressed files])
AC_MSG_RESULT($use_compression)
Is what we have in configure.ac.
if USE_COMPRESSION
COMPRESSION = gzstream.C gzstream.h
endif
from src/support/Makefile.am
--
Lgb
Re: LyX on Windows
On Sun, Jan 16, 2005 at 08:27:03PM +, Angus Leeming wrote: > Would it not be more elegant to tell Windows that LyX > is actually a GUI-based app by giving it a WinMain? Or link against qtmain.lib, which will do the same. Andre'
Re: LyX on Windows
Andre Poenitz wrote: > On Sun, Jan 16, 2005 at 08:27:03PM +, Angus Leeming wrote: >> Would it not be more elegant to tell Windows that LyX >> is actually a GUI-based app by giving it a WinMain? > > Or link against qtmain.lib, which will do the same. The consensus was to leave lyx as a console-based app, for the reasons discussed in os_win32.C. -- Angus
Re: LyX on Windows
On Tue, Jan 18, 2005 at 06:34:14PM +, Angus Leeming wrote: > Andre Poenitz wrote: > > > On Sun, Jan 16, 2005 at 08:27:03PM +, Angus Leeming wrote: > >> Would it not be more elegant to tell Windows that LyX > >> is actually a GUI-based app by giving it a WinMain? > > > > Or link against qtmain.lib, which will do the same. > > The consensus was to leave lyx as a console-based app, for the reasons > discussed in os_win32.C. Fair enough. Andre'
Re: LyX on Windows
On Tue, Jan 18, 2005 at 11:12:00AM +0100, Asger Ottar Alstrup wrote: > QMathMatrixDialog.C > c:\lyx\lyx-devel\src\frontends\qt2\QDialogView.h(113) : error C2440: > 'return' : cannot convert from 'lyx::frontend::QMathDialog *' to 'QDialog *' > Types pointed to are unrelated; conversion requires > reinterpret_cast, C-style cast or function-style cast Or maybe some '#include ' . Andre'
Re: LyX on Windows
On Tue, Jan 18, 2005 at 12:44:33PM +0100, Asger Ottar Alstrup wrote: > For those that are interested, attached is an archive of my changes so > far. Apply the patch, put os_win32.h in src/support and the rest of the > new files in development/win32. > > I'd like to commit the struct<->class, I'd personally prefer making the structs 'real' classes instead of changing these declarations all over the place - mainly for cosmetical reasons. Andre' PS: Could you also please replace the application/octet-stream in your mail with application/x-bzip2 or similar?
Re: LyX on Windows
On Mon, Jan 17, 2005 at 08:28:14PM +0100, Asger Ottar Alstrup wrote: > Tell you what: This wanker is going to continue commiting things behind > your back that I consider obvious monotoneous progress until you can > find an example which you disagree with. And at that point, I guess you > have to pull the plug and steal my karma! > > So, I'll be stretching the obviously correct rule to the limit, but I'll > not cross it too much. I am really waiting for your nose getting bloody. I announced on Tuesday at work that I know somebody who will try to convert a 3900 file project into something managable by Visual Studio. Now given that almost anybody there except me falls in the category 'VS addict' I was a bit surprised that the mildest reaction was something like 'Crazy. No way.' [And these people _are_ used to pain, so 'managable' might already bear another meaning in this audience than the one I am used to] > So far, you should not loose sleep. I still have 275 errors and 399 > warnings to combat. Like the ones you get when source files grows beyond 64k lines? 16 bit toy IDE... *eg* Nevertheless, I am looking forward to the results. I like the debugger [At least as long as strings stays small and do not have exactly 16 chars...] Andre' (right now stress-testing a mixed Motif/MFC Windows applications with linked-in X server under wine in a fvwm session displayed on a Win2k desktop. *sigh* Any obvious reason why the X server crashes wit IO error after a mere 270 million requests?)
Re: LyX on Windows
On Mon, Jan 17, 2005 at 11:55:56AM +, Angus Leeming wrote: > Asger Ottar Alstrup wrote: > > That is something to address then for a native Windows port to work out. > > I'd like to produce a native LyX binary with as few unix dependencies as > > possible. > > > > Further out, I'd even like to kick out LaTeX, and put some > > other backend in instead to reduce the footprint. Okay, now that's just plain weird. (La)TeX has been producing decent output for 2 decades. It *still* beats the undies off of any Micro$oft product. Its only problem is that its power comes at a price. LyX drops that price greatly. Always has, too. I've been looking at this whole LyX-on-Windows thingy as a way of facilitating greater ease-of-use of (La)TeX on Windows, not as a way of bypassing it. Why reinvent the wheel?!? Or to paraphrase Jamie Zawinsky: That's like banging two rocks together and being proud that you've rederived fire from first principles. It's a solved problem, and not worth revisiting. -- John Weiss
Re: LyX on Windows
On Mon, Jan 17, 2005 at 02:09:33PM +0100, Lars Gullik Bjønnes wrote: > > I feel we are beginning on a slippery slope now... ok to support > windows if only minimal changes are needed... but now we see more and > more changes needed to support this. > > I am not sure that I am really happy about this "progress" Nor should you be. Doing true full-Windows support in an inherently-unix program is a very thorny, messy situation. You start running into the need to create a totally indenpendent platform-layer, doing the equivalent of standard Posix functions with pure Win-libs often requires odd gymnastics... I could go on. Suffice it to say that it's enough to keep a CompSci PhD fully employed at one place I used to work. Best to keep things simple for now, as Lars says. -- John Weiss
Re: LyX on Windows
John Weiss wrote: Doing true full-Windows support in an inherently-unix program is a very thorny, messy situation. Have a look at the patch and then give your comments rather than this FUD. Asger Wrote: > > Further out, I'd even like to kick out LaTeX, and put some > > other backend in instead to reduce the footprint. John Weiss responded: > Okay, now that's just plain weird. Have a look at Lout: http://lout.sourceforge.net/ It's a 2 MB download, compared to 50 MB+ for LaTeX. When you have looked at that, then give reasons why this is such a weird idea. To clarify, I would never drop LaTeX support, but I'd like to make a self-contained high-quality typesetting system for Windows with as small a footprint as possible. Lout fits that purpose better than LaTeX. Basically, I believe choice is a good thing. Regards, Asger
Re: LyX on Windows
On Tue, Jan 18, 2005 at 07:36:36AM -0500, John Weiss wrote: > On Mon, Jan 17, 2005 at 02:09:33PM +0100, Lars Gullik Bjønnes wrote: > > > > I feel we are beginning on a slippery slope now... ok to support > > windows if only minimal changes are needed... but now we see more and > > more changes needed to support this. > > > > I am not sure that I am really happy about this "progress" > > Nor should you be. > > Doing true full-Windows support in an inherently-unix program is a > very thorny, messy situation. There are at least two points to be consider. First of all, it seems to bring back Asger into the boat. Secondly, having the thing compile _also_ in Visual Studio is nice, as hunting down certain bugs is much more fun when you do not have to wait several minutes for a link to finish. I don't see any particular strong reason to dislike either. Andre'
Re: LyX on Windows
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Tue, Jan 18, 2005 at 07:36:36AM -0500, John Weiss wrote: >> On Mon, Jan 17, 2005 at 02:09:33PM +0100, Lars Gullik Bjønnes wrote: >> > >> > I feel we are beginning on a slippery slope now... ok to support >> > windows if only minimal changes are needed... but now we see more and >> > more changes needed to support this. >> > >> > I am not sure that I am really happy about this "progress" >> >> Nor should you be. >> >> Doing true full-Windows support in an inherently-unix program is a >> very thorny, messy situation. > | There are at least two points to be consider. > | First of all, it seems to bring back Asger into the boat. > | Secondly, having the thing compile _also_ in Visual Studio is nice, as | hunting down certain bugs is much more fun when you do not have to wait | several minutes for a link to finish. > | I don't see any particular strong reason to dislike either. Depends. (especially the first point :-) ) Sure it is nice to compile on more than one compiler... but if the result is muddier code then I am not sure about the gain. (and not that I have not said that this is the case, just a thing to watch out for. and we already see quite a bit of preprocessors tokens entering code...) -- Lgb
Re: LyX on Windows
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> Sure it is nice to compile on more than one compiler... but if the >> result is muddier code then I am not sure about the gain. (and not >> that I have not said that this is the case, just a thing to watch out >> for. and we already see quite a bit of preprocessors tokens entering >> code...) > | Sorry, Lars, but to quote Asger, that is just FUD. Try: So drop the last sentence of the parantesis. The rest stands. -- Lgb
Re: LyX on Windows
Lars Gullik Bjønnes wrote: > | Lars Gullik Bjønnes wrote: >>> Sure it is nice to compile on more than one compiler... but if the >>> result is muddier code then I am not sure about the gain. (and not >>> that I have not said that this is the case, just a thing to watch out >>> for. and we already see quite a bit of preprocessors tokens entering >>> code...) >> > | Sorry, Lars, but to quote Asger, that is just FUD. Try: > > So drop the last sentence of the parantesis. The rest stands. I think that we're both keen that the code does not become muddied. Code muddied with preprocessor tokens usually means that a necessary abstraction isn't in place. If you look again at Asger's patch, you'll see that almost all of the remaining #ifdef _WIN32 kludges are caused by the lack of a LyX abstraction for named pipes and sockets and by the currently inadequate abstraction for external processes. I'd propose that giallo should be used for the named pipes and sockets, but not until after 1.4.0 is released. I.e., the lyxserver and lyxsocket should be disabled on LyX/Win 1.4.x. Reworking our existing child process code to move the *nix-specific code in ispell.C (that handles redirection of the child's stdin/out/err streams) behind our ForkedCall interface is easy enough. Thereafter, we'll need some Windows-specific code to do this and to tell us when a child process has exited without blocking until it has done so. I'm writing up some notes on what is needed and the available solution strategies at the moment. I'll post soon. -- Angus
Re: LyX on Windows
On Sat, Jan 22, 2005 at 03:30:44PM +0100, Asger Ottar Alstrup wrote: > John Weiss wrote: > >Doing true full-Windows support in an inherently-unix program is a > >very thorny, messy situation. > > Have a look at the patch and then give your comments rather than this FUD. Not FUD. Reality. Be fair, Asger, and include the other sentences in the paragraph. Specifically, the one about one place where I used to work. They had the *best* platform-independence-layer I've seen *anywhere* since. That layer handled, seamlessly, 3 Unix flavors and Windows NT. Took them YEARS to get it to that state. Every time we needed a new OS-level library call, it took the guy who maintained the platform-independence-layer, a really stellar, bright guy with a CompSci PhD, *at* *least* 2 weeks to get a clean, forward-maintainable implementation in place. I know; I threw in a quick-kludge for one piece of code I was working on, and didn't replace the kludge with the corresponding implementation from the P.I.-layer until months later. So, don't you *dare* accuse me of FUD; I speak from direct experience. Besides, right now (besides ad-hominem attacks) you're most likely "picking the low-hanging fruit" so to speak. It's what any good software developer would do. However, I fear, based on your dismissive reaction, that you're extrapolating your current focus to all cases. The Unix/Windows platform-indep.-layer problem isn't intractable. However, it's far from non-trivial. Eventually, Asger, you *will* hit the thornier stuff, and the pitched screaming between you and Lars will commence. > Asger Wrote: > > > Further out, I'd even like to kick out LaTeX, and put some > > > other backend in instead to reduce the footprint. > > Then Asger Wrote: > > To clarify, I would never drop LaTeX support, Language Lesson: In most dialects of English, those two statements are mutually exclusive. The only dialect where it's not is that spoken in Washington D.C. -- John Weiss
Re: LyX on Windows
On Sat, Jan 22, 2005 at 09:50:51AM +0100, Andre Poenitz wrote: > On Tue, Jan 18, 2005 at 07:36:36AM -0500, John Weiss wrote: > > On Mon, Jan 17, 2005 at 02:09:33PM +0100, Lars Gullik Bjønnes wrote: > > > > > > I feel we are beginning on a slippery slope now... ok to support > > > windows if only minimal changes are needed... but now we see more and > > > more changes needed to support this. > > > > > > I am not sure that I am really happy about this "progress" > > > > Nor should you be. > > > > Doing true full-Windows support in an inherently-unix program is a > > very thorny, messy situation. > > > I don't see any particular strong reason to dislike either. It's not a matter of dislike. It's a warning: There Be Dragons Here. And, it's a warning from someone who's spoken with the knights who went into that cave before, long ago. And who has a scorchmark or two of his own. BTW: Thanks, Andre, for reminding me *why* I responded in the first place, a response rather unfairly dismissed by Asger with an ad-hominem attack. The arguing *has* already started. Guys, guys: There's a reason why a Proxy-API like Cygwin exists. (By "Proxy", I mean the design-patterns defn. of the term.) Because, eventually, any program that supports both Windows and Unix will have to make some of its calls through such a platform-independent Proxy-API. Whether that Proxy-API is someone else's do-everything-for-everyone solution (like Cygwin), or whether you implement it yourself just for your program is immaterial. The exercise of writing those Proxy classes can be a lot of fun. Nevertheless, someone will need to do it and it will take effort. (IIRC, the guy I keep mentioning from where I used to work had also done some platform-independence-layer-stuff for VAX<-->Unix, and it wasn't any easier. Seems to be the nature of the beast.) P.S.: I'm not saying all of this to be discouraging. Asger, by all means, *do* write a good pi-layer for LyX. You're certainly capable of it. I'm just saying that you're heading into the Dragons' Cave with nowhere near as much armor as those who trod in before you wore. :) -- John Weiss
Re: LyX on Windows
John Weiss wrote: [A great opportunity to have a little flame-fest.] Not FUD. Reality. [Long story about something irrelevant.] > Took them YEARS to get it to that state. Sad for them. I have a working LyX. It took a week of work while Elias was sleeping. All you are saying is FUD, and the proof is in the code. You can repeat the same stories ten times, but they will still be FUD. Asger Wrote: Further out, I'd even like to kick out LaTeX, and put some other backend in instead to reduce the footprint. Then Asger Wrote: To clarify, I would never drop LaTeX support, Language Lesson: In most dialects of English, those two statements are mutually exclusive. The only dialect where it's not is that spoken in Washington D.C. The first is referering to a full installation package, while the second is refering to the LyX executable. You might have figured that out if you have been reading what I have been writing, rather than spending your time spreading FUD and innuendo. Regards, Asger
Re: LyX on Windows
On Mon, Jan 24, 2005 at 10:01:09AM +0100, Lars Gullik Bjønnes wrote: > > Sure it is nice to compile on more than one compiler... but if the > result is muddier code then I am not sure about the gain. (and not > that I have not said that this is the case, just a thing to watch out > for. And avoiding muddy code in a Unix-Windows-crossplatform program will require a bit of work (in which I include careful planning). Which was the whole point of those cautioning posts of mine. -- John Weiss
Re: LyX on Windows
John Weiss wrote: > And avoiding muddy code in a Unix-Windows-crossplatform program will > require a bit of work (in which I include careful planning). Which > was the whole point of those cautioning posts of mine. Oh, read the code, John, read the code. There's a bit of hacking to do still in support/filetools.[Ch], support/FileInfo.[Ch] and support/forkedcall.[Ch], support/forkedcontr[Ch] (notice that these are in the *support* library), but the work is actually a case of merging stuff that's already been written into the repository. I'm not saying that writing cross-platform code is easy. I'm saying that we use the right tools to make it easy FOR US. Specifically, a cross-platform GUI (Qt) and the Boost libraries. Have a nice Friday and a fun w/e. -- Angus
Re: LyX on Windows
On Tue, Jan 25, 2005 at 09:16:38AM +0100, Asger Ottar Alstrup wrote: > John Weiss wrote: > [A great opportunity to have a little flame-fest.] > > >Not FUD. Reality. [Long story about something irrelevant.] > > Took them YEARS to get it to that state. > > Sad for them. I have a working LyX. It took a week of work while Elias > was sleeping. All you are saying is FUD, and the proof is in the code. Since we are at it: I had a look at the .vcproj and a more recent (and therefore possibly incompatible) version of LyX sources. Patch applied nicely, however I was not able get anywhere near a full compile. Compilation succeed for individual files, but there seemed to be files missing from boost (something with while.hpp and soemthing with msvc somewhere in the path). Are you building from a clean check out with only your patch applied? Do you have the boost path in your VS settings? Just '../../boost' is certainly not enough when you access the Andre'
Re: LyX on Windows
Andre Poenitz wrote: Since we are at it: I had a look at the .vcproj and a more recent (and therefore possibly incompatible) version of LyX sources. Patch applied nicely, however I was not able get anywhere near a full compile. Compilation succeed for individual files, but there seemed to be files missing from boost (something with while.hpp and soemthing with msvc somewhere in the path). I believe I did add all necessary boost files to the CVS. Please try again with a fresh update. Are you building from a clean check out with only your patch applied? Do you have the boost path in your VS settings? Just '../../boost' is certainly not enough when you access the I do not have time to do a clean check out and apply the patch, but I think everything should be set up correctly in the project file. It is enough with a bunch of include directives to the boost files here. Regards, Asger
Re: LyX on Windows
Lars Gullik Bjønnes wrote: > Sure it is nice to compile on more than one compiler... but if the > result is muddier code then I am not sure about the gain. (and not > that I have not said that this is the case, just a thing to watch out > for. and we already see quite a bit of preprocessors tokens entering > code...) Sorry, Lars, but to quote Asger, that is just FUD. Try: $ grep -r '#if' src | \ grep -v ChangeLog | \ grep -v 'config\.h' | \ grep -v ':#ifndef .*_H$' | \ grep -v WITH_WARNINGS | \ grep -v _GLIBCPP_CONCEPT_CHECKS | \ grep -v '#if [01]' | \ grep -v '__cplusplus' > preproc.txt The resulting file is 300+ lines long and, of those 300+ lines, these ones are relatively new: src/lyx_main.C:#ifdef SIGHUP src/buffer.C:#ifdef USE_COMPRESSION src/lyxlex_pimpl.C:#ifdef USE_COMPRESSION src/lyxlex_pimpl.h:#ifdef USE_COMPRESSION src/frontends/qt2/QPrefs.C:#if defined(__CYGWIN__) || defined(__CYGWIN32__) src/frontends/qt2/QPrefsDialog.C:#if defined(__CYGWIN__) || defined(__CYGWIN32__) src/frontends/xforms/FormPreferences.C:#if defined(__CYGWIN__) || defined(__CYGWIN32__) src/support/package.C.in:#if defined (USE_WINDOWS_PACKAGING) || defined (USE_MACOSX_PACKAGING) The USE_COMPRESSION stuff should probably have been there from the beginning, the __CYGWIN__ stuff in the preferences dialog is Kayvan's "let the user decide how paths are output under Cygwin" stuff and the PACKAGING stuff is, well, packaging. The only preprocessor token that's left is the SIGHUP define. That doesn't seem to me to be muddying the source particularly. -- Angus
Re: LyX on windows performance
Am Samstag, 23. Dezember 2017 um 20:35:04, schrieb Jean-Marc Lasgouttes > Hi there, > > I took the dive to compile LyX on windows 10. Interesting experiment... > Intalling Visual studio takes maybe one hour (not downloading), Qt takes > just as much, selecting what platform to install is like evading a maze. > > But, thanks to the nice INSTALL file, I did it (Qt 5.9.3 64bits) for > 2.3.x+properpaint branch (I will switch to master soon). > > First (good) news: there is no black screen like on the Mac. > > Second (bad) news: the performance is terrible, much worse that 2.2.3 as > packaged by Uwe. Uwe, what is your secret? Do I have to set some > optimization level? > > I tried to run with a profiler (Very Sleepy CS), but without debug I do > not see any LyX function, and with debug what I see is some string > manipulation from the C++ library. > > What does debug mean? Is this only debug information or also > instrumenting for run-time checking? Only Debug information. Also the optimization is turned to -O0 > Kornel, what is a good set of parameters for profiling? > > JMarc I would try -DLYX_DEBUG=ON -DLYX_PROFILE=ON -DLYX_CONSOLE=ON and without -DLYX_INSTALL=ON, because this disables profiling on Windows. (You may comment the CMakeLists.txt:196 line #set(LYX_PROFILE OFF) ) but mark, my knowledge about Windows is nearly to nothing. Also you may need 'gprof'. Of course, I could never test it. Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX on windows performance
Le 24/12/2017 à 06:18, Kornel Benko a écrit : What does debug mean? Is this only debug information or also instrumenting for run-time checking? Only Debug information. Also the optimization is turned to -O0 OK. Kornel, what is a good set of parameters for profiling? I would try -DLYX_DEBUG=ON -DLYX_PROFILE=ON -DLYX_CONSOLE=ON and without -DLYX_INSTALL=ON, because this disables profiling on Windows. (You may comment the CMakeLists.txt:196 line #set(LYX_PROFILE OFF) ) but mark, my knowledge about Windows is nearly to nothing. Also you may need 'gprof'. Actually, gprof is no good for LyX, and is only for gcc. What I use these days is a build with full optimization and debug information. You can run that under a system level debugger and get good results. You can take a look at the matrix of settings for the --enable-build-type option in INSTALL to see the autoconf choices. JMarc
Re: LyX on windows performance
Am Sonntag, 24. Dezember 2017 um 12:39:16, schrieb Jean-Marc Lasgouttes > Le 24/12/2017 à 06:18, Kornel Benko a écrit : > >> What does debug mean? Is this only debug information or also > >> instrumenting for run-time checking? > > > > Only Debug information. Also the optimization is turned to -O0 > > OK. > > >> Kornel, what is a good set of parameters for profiling? > > > I would try > > -DLYX_DEBUG=ON -DLYX_PROFILE=ON -DLYX_CONSOLE=ON > > and without -DLYX_INSTALL=ON, because this disables profiling on Windows. > > (You may comment the CMakeLists.txt:196 line > > #set(LYX_PROFILE OFF) > > ) > > but mark, my knowledge about Windows is nearly to nothing. > > Also you may need 'gprof'. > > Actually, gprof is no good for LyX, and is only for gcc. What I use > these days is a build with full optimization and debug information. You > can run that under a system level debugger and get good results. > > You can take a look at the matrix of settings for the > --enable-build-type option in INSTALL to see the autoconf choices. > > JMarc But does it apply to MSVC? I could not see In cmake we have Debug, Release, RelWithDebInfo, MinSizeRel. But no profiling for MSVC. Explicitly disabled by Peter Kümmel. And he knows better. In INSTALL: The `profiling' build type uses the -fno-omit-frame-pointer option with gcc But again: what to do for MSVC? I am as clueless as before. Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX on windows performance
Le 24/12/2017 à 14:00, Kornel Benko a écrit : But does it apply to MSVC? I could not see In cmake we have Debug, Release, RelWithDebInfo, MinSizeRel. But no profiling for MSVC. Explicitly disabled by Peter Kümmel. And he knows better. Well, profiling should be done with correct optimization (one wants to understand the performance of the relase version) and with debug information so that windows can tell me which function is a problem. Looking a bit around, I found this: https://msdn.microsoft.com/en-us/library/ms182372.aspx So it might be that a release build is enough for profiling. I will experiment with this next week. In INSTALL: The `profiling' build type uses the -fno-omit-frame-pointer option with gcc But again: what to do for MSVC? I am as clueless as before. I do not think this is needed. JMarc
Re: LyX on windows performance
Am Sonntag, 24. Dezember 2017 um 14:23:34, schrieb Jean-Marc Lasgouttes > Le 24/12/2017 à 14:00, Kornel Benko a écrit : > > But does it apply to MSVC? I could not see > > In cmake we have Debug, Release, RelWithDebInfo, MinSizeRel. > > But no profiling for MSVC. Explicitly disabled by Peter Kümmel. > > And he knows better. > > Well, profiling should be done with correct optimization (one wants to > understand the performance of the relase version) and with debug > information so that windows can tell me which function is a problem. OK > Looking a bit around, I found this: > https://msdn.microsoft.com/en-us/library/ms182372.aspx Nice. > So it might be that a release build is enough for profiling. I will > experiment with this next week. Hopefully with success :) > > In INSTALL: > > The `profiling' build type uses the -fno-omit-frame-pointer option with > > gcc > > But again: what to do for MSVC? I am as clueless as before. > > I do not think this is needed. > > JMarc Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX on windows performance
Am 23.12.2017 um 20:35 schrieb Jean-Marc Lasgouttes: But, thanks to the nice INSTALL file, I did it (Qt 5.9.3 64bits) for 2.3.x+properpaint branch (I will switch to master soon). Cool. So I am not alone anymore on Windows. LyX is not yet ready for 64bit. This is something we should do for LyX 2.4. Therefore I am sure that you get troubles. Also note that I use MSVC 2015 because there are still issues with Qt and MSVC 2017. Second (bad) news: the performance is terrible, much worse that 2.2.3 as packaged by Uwe. Uwe, what is your secret? Do I have to set some optimization level? - use the 32bit Qt - write a batch script that does nothing more than to load this: C:\Program Files\Microsoft Visual Studio 11.0\VC\vcvarsall.bat (change it to the path of your 32bit MSVC) - double-click on this batch file. A console pops up where the MSVC environment is loaded - in the command line switch to LyX's Git folder /development/CMake and execute there the command build5-2015 install (before please check that the paths in the file build5-2015.bat are correct for your system) That's it. - optional: in 32bit MSVC set "Release" as build option. If you select "Debug" you get a dog slow build but one you can debug. (Despite I was never able to get the debugger running) I see that point 6 of http://www.lyx.org/trac/browser/lyxgit/INSTALL.Win32 is not correct. - At first just start the CMake Gui - set there the GNUWIN32 directory and the CMAKE_PATH_PREFIX directory - press generate in CMake and fix the missing paths it might complain about - press generate again then build - from now on use the build5-2015.bat file to build In the CMake GUI you might set how LyX is built. When I am back home in January, I will send you my settings. - Btw. I cannot send at the moment mails to lyx-devel directly. It only works by writing to the Gmane newsgroup. I get: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: Reason: delivery retry timeout exceeded regards Uwe
Re: LyX on Windows - Experience Report
[EMAIL PROTECTED] wrote:
>
> Dear Angus,
>
> I tried to edit/view a document which was located at
>
>"c:\Dokumente und Einstellungen\michael\Eigene Dateien"
>
> but I failed for several reasons:
>
> 1. BibTeX, Version 0.99c (MiKTeX 2.4) cannot handle spaces
>
>White space in argument---line 66 of file doc.aux
> : \bibdata{"C:/Dokumente
> :und Einstellungen/michael/Eigene
> Dateien/doc"}
>I'm skipping whatever remains of this command
Well then. Looks pretty conclusive to me. Not much we can do about that if
the underlying software can't cope.
Does it help if you use a relative path or create a shortcut from your
document dir to the bibtex database?
> 2. YAP (Yet Another Previewer) cannot display my graphics:
>
>Cannot find file "".
Go and grab clean_dvi.py from
http://wiki.lyx.org/LaTeX/FilesWithSpecialChars
> 3. Graphics conversion for PDFLaTeX fails (MikTeX Ghostscript 8.15)
Sigh. Michael, what sort of bug report is this? Does your graphics
conversion fall through to convertDefault.sh or do you use your own
EPS->PDF converter? Etc, etc.
> Looks like there are still a few problems left to be solved...
> Regards, Michael
--
Angus
Re: LyX on Windows - Experience Report
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> [EMAIL PROTECTED] wrote:
>> Dear Angus,
>>
>> I tried to edit/view a document which was located at
>>
>> "c:\Dokumente und Einstellungen\michael\Eigene Dateien"
>>
>> but I failed for several reasons:
>>
>> 1. BibTeX, Version 0.99c (MiKTeX 2.4) cannot handle spaces
>>
>> White space in argument---line 66 of file doc.aux :
>> \bibdata{"C:/Dokumente : und Einstellungen/michael/Eigene
>> Dateien/doc"} I'm skipping whatever remains of this command
Angus> Well then. Looks pretty conclusive to me. Not much we can do
Angus> about that if the underlying software can't cope.
Is it really needed to use quotes for a \bibliography call? This is
not really a case of underlying \input, after all. It may be that
latex_path is not necessary in this case.
JMarc
Re: LyX on Windows - Experience Report
Jean-Marc Lasgouttes wrote:
>>> Dear Angus,
>>>
>>> I tried to edit/view a document which was located at
>>>
>>> "c:\Dokumente und Einstellungen\michael\Eigene Dateien"
>>>
>>> but I failed for several reasons:
>>>
>>> 1. BibTeX, Version 0.99c (MiKTeX 2.4) cannot handle spaces
>>>
>>> White space in argument---line 66 of file doc.aux :
>>> \bibdata{"C:/Dokumente : und Einstellungen/michael/Eigene
>>> Dateien/doc"} I'm skipping whatever remains of this command
>
> Angus> Well then. Looks pretty conclusive to me. Not much we can do
> Angus> about that if the underlying software can't cope.
>
> Is it really needed to use quotes for a \bibliography call? This is
> not really a case of underlying \input, after all. It may be that
> latex_path is not necessary in this case.
It would be nice if someone else took up the baton on this one. I feel
sort of snowed under by LyX ATM :(
--
Angus
Re: Lyx on Windows 7 Bug
Just as a follow-up. This is bug http://www.lyx.org/trac/ticket/7187 and will be fixed in the next release. Vincent
Re: Lyx on Windows 7 Bug
Op 21-7-2010 18:08, Larry Maturo schreef: I have a 64 bit Windows 7 installation. The install of Lyx version 167-4-25 went very smoothly. However, when it came up the text on the screen was virtually unintelligible. I brought up the DVI and printed it out and that was just fine. After playing with it for a while I believe the problem is that it is not putting spaces between words. Not only is it not putting spaces between words, but it seems to be overlapping the first character in the word after the space with the last character in the word before the space, which makes things even more unreadable. I believe that is why I had such a hard time trying to read the "Welcome to Lyx!" document. I'm a software developer, so if there is anything I can do to help you with debugging this just let me know. Can you show us a screenshot or the like ? Vincent
Re: LyX on Windows (MinGW) - Font problem
Michael Gerz wrote: > Ok, > > I am able to run LyX on Windows again. However, the selected font is > pretty ugly. It seems that LyX 1.4 is not able to find reasonable fonts > (LyX 1.3 does!) and so Qt decides to take the first font in > alphabetically order. This font is not only choosen for displaying a LyX > document but also for all Qt dialogs (title bar, labels, text fields, > etc.)! > > Does anybody know where I can find the code that decides which font is > to be used for Qt dialogs? Not in LyX. qtconfig in your qt3/bin directory. -- Angus
Re: LyX on Windows (MinGW) - Font problem
Angus Leeming wrote: Not in LyX. qtconfig in your qt3/bin directory. That doesn't really explain why LyX 1.3 behaves correctly where LyX 1.4 does not. Michael
Re: LyX on Windows (MinGW) - Font problem
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes: Michael> Angus Leeming wrote: >> Not in LyX. >> >> qtconfig in your qt3/bin directory. >> >> Michael> That doesn't really explain why LyX 1.3 behaves correctly Michael> where LyX 1.4 does not. What are the values of the font-related preferences? JMarc
Re: LyX on Windows (MinGW) - Font problem
Jean-Marc Lasgouttes wrote: Michael> That doesn't really explain why LyX 1.3 behaves correctly Michael> where LyX 1.4 does not. What are the values of the font-related preferences? Sorry, I was wrong. The problem occurs with 1.4 and 1.3. It is definitely a Q.../Free problem. I have already informed Christian Ehrlicher about it. Michael
Re: LyX on Windows: New Wiki Pages
Richard Kimberly Heck wrote: > Soon, I am going to write small batch file that people can use to > install various packages that LyX might want. I'll link that off the > wiki, and probably include it in the Windows installer. I mean just the > file itself. Not running it as part of the installer. Once we collect set of packages/binaries we want by default from texlive we could write to texlive mailling list and ask them if they would be willing to create lyx-scheme for us directly in the installer... Pavel
Re: LyX on Windows: New Wiki Pages
On 09/09/2018 01:35, Richard Kimberly Heck wrote: As mentioned previously, I am not going to build a "bundled" installer for 2.3.1. Indeed, I have removed the 'bundle' code from the installer at 8c32a1a7 and removed the bundled installer for 2.3.0 from the downloads page. I've added language instructing people to install a TeX distribution before installing LyX (as we do for OSX). I have also written this wiki page https://wiki.lyx.org/Windows/TeXLive to help people install TeXLive and this page https://wiki.lyx.org/LaTeX/TeXLivePackages to help people learn how to install packages. I'd appreciate it if people could have a look and make whatever changes or additions seem worth making. We could probably use, on one of those two pages, a quick guide to updating the TeXLive packages using the GUI. Soon, I am going to write small batch file that people can use to install various packages that LyX might want. I'll link that off the wiki, and probably include it in the Windows installer. I mean just the file itself. Not running it as part of the installer. Riki Thanks. That will hopefully help many users. But maybe there is still a problem for non-English speakers? Daniel
Re: LyX on Windows: New Wiki Pages
On 09/09/2018 07:32 AM, Daniel wrote: > On 09/09/2018 01:35, Richard Kimberly Heck wrote: >> As mentioned previously, I am not going to build a "bundled" installer >> for 2.3.1. Indeed, I have removed the 'bundle' code from the installer >> at 8c32a1a7 and removed the bundled installer for 2.3.0 from the >> downloads page. I've added language instructing people to install a TeX >> distribution before installing LyX (as we do for OSX). >> >> I have also written this wiki page >> >> https://wiki.lyx.org/Windows/TeXLive >> >> to help people install TeXLive and this page >> >> https://wiki.lyx.org/LaTeX/TeXLivePackages >> >> to help people learn how to install packages. I'd appreciate it if >> people could have a look and make whatever changes or additions seem >> worth making. We could probably use, on one of those two pages, a quick >> guide to updating the TeXLive packages using the GUI. >> >> Soon, I am going to write small batch file that people can use to >> install various packages that LyX might want. I'll link that off the >> wiki, and probably include it in the Windows installer. I mean just the >> file itself. Not running it as part of the installer. >> >> Riki > > Thanks. That will hopefully help many users. But maybe there is still > a problem for non-English speakers? We could work to get this translated, but I'm not sure how. Riki
Re: LyX on Windows: New Wiki Pages
On 09/09/2018 04:20 AM, Pavel Sanda wrote: > Richard Kimberly Heck wrote: >> Soon, I am going to write small batch file that people can use to >> install various packages that LyX might want. I'll link that off the >> wiki, and probably include it in the Windows installer. I mean just the >> file itself. Not running it as part of the installer. > Once we collect set of packages/binaries we want by default from texlive > we could write to texlive mailling list and ask them if they would > be willing to create lyx-scheme for us directly in the installer... What a great idea! The file development/Win32/packaging/installer/Packages.txt is what Uwe used to tell MiKTeX what to install (and which I'll use to build the batch files). I believe it is meant to include everything that LyX could ever possibly want. That would do, I suppose. It's 319 packages, or so says 'wc -l', but it probably doesn't end up being a whole ton of space, and some of them may already be installed. Alternatively, we could try to pare the list down a bit to packages people are more likely to need. Riki
Re: LyX on Windows: New Wiki Pages
On 09/09/2018 18:12, Richard Kimberly Heck wrote: On 09/09/2018 07:32 AM, Daniel wrote: On 09/09/2018 01:35, Richard Kimberly Heck wrote: As mentioned previously, I am not going to build a "bundled" installer for 2.3.1. Indeed, I have removed the 'bundle' code from the installer at 8c32a1a7 and removed the bundled installer for 2.3.0 from the downloads page. I've added language instructing people to install a TeX distribution before installing LyX (as we do for OSX). I have also written this wiki page https://wiki.lyx.org/Windows/TeXLive to help people install TeXLive and this page https://wiki.lyx.org/LaTeX/TeXLivePackages to help people learn how to install packages. I'd appreciate it if people could have a look and make whatever changes or additions seem worth making. We could probably use, on one of those two pages, a quick guide to updating the TeXLive packages using the GUI. Soon, I am going to write small batch file that people can use to install various packages that LyX might want. I'll link that off the wiki, and probably include it in the Windows installer. I mean just the file itself. Not running it as part of the installer. Riki Thanks. That will hopefully help many users. But maybe there is still a problem for non-English speakers? We could work to get this translated, but I'm not sure how. Riki I am not sure either. Unfortunately, there are no translated instructions on the MiKTeX and TeX Live websites either, as far as I could see. But their installers might be or they are at least pretty much straight forward. Maybe there could be a link in the LyX installer that opens the download website (if they are stable)? That might help some people to quickly get going. Daniel
Re: LyX on Windows: New Wiki Pages
On 09/09/2018 12:23 PM, Daniel wrote: > On 09/09/2018 18:12, Richard Kimberly Heck wrote: >> On 09/09/2018 07:32 AM, Daniel wrote: >>> On 09/09/2018 01:35, Richard Kimberly Heck wrote: As mentioned previously, I am not going to build a "bundled" installer for 2.3.1. Indeed, I have removed the 'bundle' code from the installer at 8c32a1a7 and removed the bundled installer for 2.3.0 from the downloads page. I've added language instructing people to install a TeX distribution before installing LyX (as we do for OSX). I have also written this wiki page https://wiki.lyx.org/Windows/TeXLive to help people install TeXLive and this page https://wiki.lyx.org/LaTeX/TeXLivePackages to help people learn how to install packages. I'd appreciate it if people could have a look and make whatever changes or additions seem worth making. We could probably use, on one of those two pages, a quick guide to updating the TeXLive packages using the GUI. Soon, I am going to write small batch file that people can use to install various packages that LyX might want. I'll link that off the wiki, and probably include it in the Windows installer. I mean just the file itself. Not running it as part of the installer. Riki >>> >>> Thanks. That will hopefully help many users. But maybe there is still >>> a problem for non-English speakers? >> >> We could work to get this translated, but I'm not sure how. >> >> Riki >> >> > > I am not sure either. Unfortunately, there are no translated > instructions on the MiKTeX and TeX Live websites either, as far as I > could see. But their installers might be or they are at least pretty > much straight forward. Maybe there could be a link in the LyX > installer that opens the download website (if they are stable)? That > might help some people to quickly get going. It's really preferable that TeX be set up before the LyX installation. I mean, we could create two new 'bundled' installers that did nothing but launch the TeX install for people, but I'm not sure I see the point of that. I think we should really re-think 'bundling' ImageMagick, etc, in the way we do, as well. Presently, it's not at all obvious how a user could update ImageMagick itself in the wake of the kinds of security issues we've just seen. You'd have to re-install LyX, really...and wait for us to release an updated installer. I guess I really need to update the included ImageMagick, but I'm not totally sure how to do that yet. Riki
Re: LyX on Windows: New Wiki Pages
On 09/09/2018 18:38, Richard Kimberly Heck wrote: On 09/09/2018 12:23 PM, Daniel wrote: On 09/09/2018 18:12, Richard Kimberly Heck wrote: On 09/09/2018 07:32 AM, Daniel wrote: On 09/09/2018 01:35, Richard Kimberly Heck wrote: As mentioned previously, I am not going to build a "bundled" installer for 2.3.1. Indeed, I have removed the 'bundle' code from the installer at 8c32a1a7 and removed the bundled installer for 2.3.0 from the downloads page. I've added language instructing people to install a TeX distribution before installing LyX (as we do for OSX). I have also written this wiki page https://wiki.lyx.org/Windows/TeXLive to help people install TeXLive and this page https://wiki.lyx.org/LaTeX/TeXLivePackages to help people learn how to install packages. I'd appreciate it if people could have a look and make whatever changes or additions seem worth making. We could probably use, on one of those two pages, a quick guide to updating the TeXLive packages using the GUI. Soon, I am going to write small batch file that people can use to install various packages that LyX might want. I'll link that off the wiki, and probably include it in the Windows installer. I mean just the file itself. Not running it as part of the installer. Riki Thanks. That will hopefully help many users. But maybe there is still a problem for non-English speakers? We could work to get this translated, but I'm not sure how. Riki I am not sure either. Unfortunately, there are no translated instructions on the MiKTeX and TeX Live websites either, as far as I could see. But their installers might be or they are at least pretty much straight forward. Maybe there could be a link in the LyX installer that opens the download website (if they are stable)? That might help some people to quickly get going. It's really preferable that TeX be set up before the LyX installation. I mean, we could create two new 'bundled' installers that did nothing but launch the TeX install for people, but I'm not sure I see the point of that. I think we should really re-think 'bundling' ImageMagick, etc, in the way we do, as well. Presently, it's not at all obvious how a user could update ImageMagick itself in the wake of the kinds of security issues we've just seen. You'd have to re-install LyX, really...and wait for us to release an updated installer. I guess I really need to update the included ImageMagick, but I'm not totally sure how to do that yet. I wasn't suggesting to install TeX after the installation. Rather, when LyX is searching for TeX but doesn't find any, it offers links to a TeX installer website and tells them to install it before proceeding with the LyX install. Since there is no automatic dependency installation, it could at least make it easier to take this hurdle in order to install LyX. Daniel
Re: LyX on Windows: New Wiki Pages
Richard Kimberly Heck wrote: > What a great idea! The file > development/Win32/packaging/installer/Packages.txt > is what Uwe used to tell MiKTeX what to install (and which I'll use to > build the batch files). I believe it is meant to include everything that > LyX could ever possibly want. That would do, I suppose. It's 319 > packages, or so says 'wc -l', but it probably doesn't end up being a > whole ton of space, and some of them may already be installed. > Alternatively, we could try to pare the list down a bit to packages > people are more likely to need. If we wanted to spare some download time/install time the best place would be to strip the docs. I measured it some time ago - the basic TL packages nedeed were ~300 mb and their documentation 1.5 GB... I'm pretty sure instaler could be instructed not to use the docs. Pavel
Re: LyX on Windows with UNC home directories
On 21/03/2012 11:10 AM, Matthias Hunstig wrote: Dear LyX users and developers, LyX has a problem with Windows users that have their home directory on a UNC path. http://wiki.lyx.org/LyX/Troubleshooting mentions these problems for Lyx 1.5 already. (Recent versions do start, but have no classes available.) I have been struggling with this for a long time. The workaround described in the link (saving some steps by running configure.py directly from the AppData\Lyx2.0 folder) worked for me on Windows XP. Now, on Windows 7, it does not work anymore. Today, I have done some experiments but unfortunately not found a solution yet. What I have found out is that - Under local users, LyX states "~\AppData\Roaming\Lyx2.0" as the user directory. I have not seen the tilde on Windows before, but it works. - Under network users, it states "\\server\user\ntdata\Anwendungsdaten\LyX2.0" as the user directory. - Running reconfigure from LyX as the network user gives some messages in the status line that can be traced back to the fact that cmd.exe does not accept UNC folders. Is there any way to reliably make LyX run as a user with a UNC home directory? Could it help to just give LyX a different user directory to work in? If so, how can that be done? I think this issue really needs to be fixed soon - People with home directories on serves are not uncommon and LyX is practically unusable for them. Regards Matthias Hi Matthias, Thanks for the descriptive report of the problem and your investigation of it. Please, could you add a ticket to the bug tracker at http://www.lyx.org/trac/wiki/BugTrackerHome with as much information as you can. Your email already is very descriptive of your investigation, it would help to have this recorded on the bug tracker until someone tries to tackle the bug. I'm also cc'ing the dev list to see if anyone has any immediate ideas. Regards, Julien
Re: LyX on Windows with UNC home directories
Il 22/03/2012 20:09, Julien Rioux ha scritto: On 21/03/2012 11:10 AM, Matthias Hunstig wrote: Dear LyX users and developers, LyX has a problem with Windows users that have their home directory on a UNC path. http://wiki.lyx.org/LyX/Troubleshooting mentions these problems for Lyx 1.5 already. (Recent versions do start, but have no classes available.) I have been struggling with this for a long time. The workaround described in the link (saving some steps by running configure.py directly from the AppData\Lyx2.0 folder) worked for me on Windows XP. Now, on Windows 7, it does not work anymore. Today, I have done some experiments but unfortunately not found a solution yet. What I have found out is that - Under local users, LyX states "~\AppData\Roaming\Lyx2.0" as the user directory. I have not seen the tilde on Windows before, but it works. - Under network users, it states "\\server\user\ntdata\Anwendungsdaten\LyX2.0" as the user directory. - Running reconfigure from LyX as the network user gives some messages in the status line that can be traced back to the fact that cmd.exe does not accept UNC folders. Is there any way to reliably make LyX run as a user with a UNC home directory? Could it help to just give LyX a different user directory to work in? If so, how can that be done? Please, see the "-userdir" command-line option. T.
