Re: reLyX - tex2lyx - maturity
Lars Gullik Bjønnes wrote: How mature is tex2lyx? Is it anywhere close to replace reLyX? I have successfully used tex2lyx to convert a big document (~230 pages, lots of formulas and figures, edited by several authors with very different latex knowledge) last month. I found and fixed some bugs during this process (also the environment nesting bug that was the only remaining one that showed up when converting the userguide), and will feed them back when I find some time and the rest of the graphics conversion bugs are done. tex2lyx hase some problems with tables, but I don't know if reLyX is better there. The rest (at least my fixed version) is in my experience already better than reLyX, so IMHO tex2lyx could become the default converter. Georg
Re: reLyX - tex2lyx - maturity
Georg Baum [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: How mature is tex2lyx? Is it anywhere close to replace reLyX? | I have successfully used tex2lyx to convert a big document (~230 pages, lots | of formulas and figures, edited by several authors with very different | latex knowledge) last month. I found and fixed some bugs during this | process (also the environment nesting bug that was the only remaining one | that showed up when converting the userguide), and will feed them back when | I find some time and the rest of the graphics conversion bugs are done. Very good. (please find time :-) ) | tex2lyx hase some problems with tables, but I don't know if reLyX is better | there. The rest (at least my fixed version) is in my experience already | better than reLyX, so IMHO tex2lyx could become the default converter. Ok. The reason for my question is that I want to get rid of reLyX completely, but only if we have a working alternative. (tex2lyx) -- Lgb
[OT] 'virulent' GPL
Hi all, you won't believe it, but some people are paranoid enough to think that using LyX to write a document somehow 'infects' the document with the GPL. That is, the document and its contents automatically become GPL too. I know this is stupid. Could anyone point me to a suitable legal document which states this isn't the case under GPL? It would help me resolve a dispute I still can't belive I'm having. Kind regards, Iwo
Re: [OT] 'virulent' GPL
Iwo Mergler wrote: Could anyone point me to a suitable legal document which states this isn't the case under GPL? It would help me resolve a dispute I still can't belive I'm having. The GPL itself? §0: [...] Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. Also see the GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html#GPLOutput Regards, Jürgen.
future of win32 port?
Dear LyX developers, thank you (again) for your LyX development. After some pause I'm again with LyX (hoping) to stay :-) Since it is such a good program I'd liek to share it with some friends who are still on Win32 platform. It's not easy to persuade Word user in a LaTeX/TeX world, but LyX can bridge the gap nicely. However, I'm concerned abut the future of Win32 port since it is based on free version of qt which is not offered for the latest qt incarnations. Does it mean that win32 port is cursed to stay in the old mud? Has anyone considered to do a wxWidgets port? Is it a big task considering the present status of LyX's GUI-independence? Sincerely, Gour -- Gour| [EMAIL PROTECTED] Registered Linux User | #278493 GPG Public Key | 8C44EDCD pgpHd0VcBqeDq.pgp Description: PGP signature
One reason for failure of external scripts on Win32
On Tuesday 01 June 2004 6:45 pm, Angus Leeming wrote: On Tuesday 01 June 2004 6:27 pm, Timm Danker wrote: Angus, I just realised that I get the same error message regardless whats in the lyxpreview2bitmap.sh. its sufficient that it is just there in the ./lyx/scripts directory. its not evaluated it seems. this is the error message C:/Dokumente: C:/Dokumente: No such file or directory LyX: Child (pid: 220) stopped on signal 0. Waiting for child to finish. LyX: Error waiting for child: No child processes note that with my way of placing the files, it works fine for me. But since you seem to dislike a solution that not uses the ./lyx directory, it would be nice for the other wiki users if we find out whats going on here. Tell me if i can be helpful with testing or something. Timm Yes, that makes sense. The script is invoked by LyX as: sh C:/Dokumente und Einstellungen/.lyx/scripts/lyxpreview2bitmap.sh other options We should wrap the name in quotes. H. Can you invoke an executable wrapped in quotes. What's the result of running this from the command line? PROMPT echo angus | sed s/a/b/ Here, on a unix box, I get 'bngus', indicating all worked as expected. Timm confirms that this works on Win32 also, so it seems that we have a way out: when invoking an external script, we should wrap the argument in quotes (using QuoteName) if we have replaced one of the placeholders $$a, $$i, $$o, $$p, $$s, $$FName, $$FPath, $$AbsPath, $$RelPathMaster, $$RelPathParent, $$AbsOrRelPathMaster, $$AbsOrRelPathParent, $$Tempname, $$Sysdir, $$LyX, $$User Unfortunately, doing so is going to be a real PITA. Angus
Re: future of win32 port?
Angus Leeming ([EMAIL PROTECTED]) wrote: No. But a gtk port has made progress. (gtk is licensed under the LGPL and has been ported to Win32.) The main LyX window is functional and a couple of the dialogs have been ported. The rest of the dialogs are from the XForms frontend. Thank you for this info. Is there any reason why wxWidgets toolkit is (somehow) avoided? It's not that I'm pushing it, but, imho, it looks like a mature multi-platform toolkit with a fair licence. Sincerely, Gour -- Gour| [EMAIL PROTECTED] Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Re: future of win32 port?
Gour [EMAIL PROTECTED] writes: | Angus Leeming ([EMAIL PROTECTED]) wrote: No. But a gtk port has made progress. (gtk is licensed under the LGPL and has been ported to Win32.) The main LyX window is functional and a couple of the dialogs have been ported. The rest of the dialogs are from the XForms frontend. | Thank you for this info. | Is there any reason why wxWidgets toolkit is (somehow) avoided? Only that nobody has done, or been interested enough to do the actual work. -- Lgb
Re: future of win32 port?
On Wed, 2 Jun 2004 11:01:24 +0200 Gour [EMAIL PROTECTED] wrote: Is there any reason why wxWidgets toolkit is (somehow) avoided? Well, I think someone would have to do it :) It's not that I'm pushing it, but, imho, it looks like a mature multi-platform toolkit with a fair licence. The more natural Toolkit for LyX would be FLTK I think, because it seems to be quite close to xforms. But that would have to be done as well... Karsten
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote: My make of up-to-date LyX-CVS ends with: | Me too (well, something similar) gcc 3.5.0cvs I don't get either. I need this, to successfully compile CVS: Index: boost/boost/cstdint.hpp === RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v retrieving revision 1.5 diff -u -r1.5 cstdint.hpp --- boost/boost/cstdint.hpp 2004/02/05 09:14:14 1.5 +++ boost/boost/cstdint.hpp 2004/06/02 08:24:38 @@ -118,7 +118,7 @@ typedef uint64_t uint_fast64_t; typedef int64_t intmax_t; - typedef uint64_t uintmax_t; +// typedef uint64_t uintmax_t; # else Any ideas why this obstructs the compilation? Compiler: gcc 3.3.4 20040505 (prerelease) Regards, Rob.
Re: boost/cstdint.hpp:121: error
Rob Lahaye [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote: My make of up-to-date LyX-CVS ends with: | Me too (well, something similar) gcc 3.5.0cvs I don't get either. | I need this, to successfully compile CVS: | Index: boost/boost/cstdint.hpp | === | RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v | retrieving revision 1.5 | diff -u -r1.5 cstdint.hpp | --- boost/boost/cstdint.hpp 2004/02/05 09:14:14 1.5 | +++ boost/boost/cstdint.hpp 2004/06/02 08:24:38 | @@ -118,7 +118,7 @@ | typedef uint64_t uint_fast64_t; | typedef int64_t intmax_t; | - typedef uint64_t uintmax_t; | +// typedef uint64_t uintmax_t; | # else | Any ideas why this obstructs the compilation? | Compiler: gcc 3.3.4 20040505 (prerelease) I doubt that this has anything to do with the compiler. I do not see the problem with gcc 3.3.2 , 3.3.3 nor 3.5 prerelease. What is the full error message you get? And what kind of system are you compiling on? -- Lgb
Re: reLyX - tex2lyx - maturity
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Lars Gullik Bjønnes wrote: How mature is tex2lyx? Is it anywhere close to replace reLyX? Georg I found and fixed some bugs during this process (also the Georg environment nesting bug that was the only remaining one that Georg showed up when converting the userguide), and will feed them Georg back when I find some time and the rest of the graphics Georg conversion bugs are done. Thanks for doing that. I was dragging my feet on this one, and it seems that it paid off :) Georg tex2lyx hase some problems with tables, but I don't know if Georg reLyX is better there. The rest (at least my fixed version) is Georg in my experience already better than reLyX, so IMHO tex2lyx Georg could become the default converter. One thing that needs to be done maybe is to implement roughly the same set of command line options as reLyX. Also, there is code in reLyX to skip preamble parts generated by LyX (useful for round trip). These would be useful and easy to add. JMarc
Re: [doc] What is TOC_top/ru_TOC_top.lyx
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars What is this? Lars TOC_top/ru_TOC_top.lyx TOC_top files are documents with the proper language setting and title that are use to generate the corresponding TOC file. Does this answer your question? JMarc
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes wrote: Rob Lahaye [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote: My make of up-to-date LyX-CVS ends with: | Me too (well, something similar) gcc 3.5.0cvs I don't get either. | I need this, to successfully compile CVS: | Index: boost/boost/cstdint.hpp | === | RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v | retrieving revision 1.5 | diff -u -r1.5 cstdint.hpp | --- boost/boost/cstdint.hpp 2004/02/05 09:14:14 1.5 | +++ boost/boost/cstdint.hpp 2004/06/02 08:24:38 | @@ -118,7 +118,7 @@ | typedef uint64_t uint_fast64_t; | typedef int64_t intmax_t; | - typedef uint64_t uintmax_t; | +// typedef uint64_t uintmax_t; | # else | Any ideas why this obstructs the compilation? | Compiler: gcc 3.3.4 20040505 (prerelease) I doubt that this has anything to do with the compiler. I do not see the problem with gcc 3.3.2 , 3.3.3 nor 3.5 prerelease. What is the full error message you get? And what kind of system are you compiling on? autogen.sh: Using autoconf (GNU Autoconf) 2.53 gmake: [...snip...] gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src' source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \ depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \ depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \ /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c -o cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF .deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o In file included from ../../../../boost/boost/regex/config.hpp:54, from cpp_regex_traits.cpp:22: ../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in type `long' gmake[4]: *** [cpp_regex_traits.lo] Error 1 - FreeBSD 4.10-STABLE i386 GCC 3.3.4 20040505 (prerelease) [FreeBSD] Rob.
Re: One reason for failure of external scripts on Win32
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Timm confirms that this works on Win32 also, so it seems that Angus we have a way out: when invoking an external script, we should Angus wrap the argument in quotes (using QuoteName) if we have Angus replaced one of the placeholders $$a, $$i, $$o, $$p, $$s, Angus $$FName, $$FPath, $$AbsPath, $$RelPathMaster, $$RelPathParent, Angus $$AbsOrRelPathMaster, $$AbsOrRelPathParent, $$Tempname, Angus $$Sysdir, $$LyX, $$User Angus Unfortunately, doing so is going to be a real PITA. Why? Can't you just QuoteName every $$ substitution instead of the whole argument? JMarc
Re: [doc] What is TOC_top/ru_TOC_top.lyx
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | Lars What is this? | Lars TOC_top/ru_TOC_top.lyx | TOC_top files are documents with the proper language setting and title | that are use to generate the corresponding TOC file. | Does this answer your question? Hmm... so russian is the only language to require this? -- Lgb
Re: boost/cstdint.hpp:121: error
Rob Lahaye [EMAIL PROTECTED] writes: | autogen.sh: | Using autoconf (GNU Autoconf) 2.53 | gmake: | [...snip...] | gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src' | source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \ | depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \ | depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \ | /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c -o cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp | /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF .deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o | In file included from ../../../../boost/boost/regex/config.hpp:54, | from cpp_regex_traits.cpp:22: | ../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in | type `long' | gmake[4]: *** [cpp_regex_traits.lo] Error 1 | - | FreeBSD 4.10-STABLE i386 | GCC 3.3.4 20040505 (prerelease) [FreeBSD] Ok, it must be FreeBSD that is the problem Is uintmax_t a macro? Or uint32_t? Has inttypes.h on FreeBSD changed recently? (upgraded libc perhaps?) What is uintmax_t/uint32_t typdeffed/defined as in inttypes.h -- Lgb
Re: One reason for failure of external scripts on Win32
Jean-Marc Lasgouttes wrote: Angus Timm confirms that this works on Win32 also, so it seems that Angus we have a way out: when invoking an external script, we should Angus wrap the argument in quotes (using QuoteName) if we have Angus replaced one of the placeholders $$a, $$i, $$o, $$p, $$s, Angus $$FName, $$FPath, $$AbsPath, $$RelPathMaster, $$RelPathParent, Angus $$AbsOrRelPathMaster, $$AbsOrRelPathParent, $$Tempname, Angus $$Sysdir, $$LyX, $$User Angus Unfortunately, doing so is going to be a real PITA. Why? Can't you just QuoteName every $$ substitution instead of the whole argument? I guess that would work. The alternative is to escape 'special chars', so 'Dokumente und Einstellungen' becomes 'Dokumente\ und\ Einstellungen'. -- Angus
Re: future of win32 port?
Lars Gullik Bjnnes ([EMAIL PROTECTED]) wrote: | Is there any reason why wxWidgets toolkit is (somehow) avoided? Only that nobody has done, or been interested enough to do the actual work. Good to know that. Seeing qt port done, hearing about gtk...I thought maybe is something wrong with wxWidgets. Unfortunately I'm not qualified to do that, but maybe someone will apper to take a challenge. Sincerely, Gour -- Gour| [EMAIL PROTECTED] Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Re: future of win32 port?
Karsten Heymann ([EMAIL PROTECTED]) wrote: The more natural Toolkit for LyX would be FLTK I think, because it seems to be quite close to xforms. But that would have to be done as well... Why do you think it is more 'natural'? Since LyX is going into GUI-independence territory, can we say that some toolkit is 'more natural'? Sincerely, Gour -- Gour| [EMAIL PROTECTED] Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Re: future of win32 port?
Gour [EMAIL PROTECTED] writes: | Since LyX is going into GUI-independence territory, can we say that some | toolkit is 'more natural'? I'd say that a C++ toolkit is more natural, other than that it really doesn't matter... -- Lgb
Re: [doc] What is TOC_top/ru_TOC_top.lyx
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars | Lars What is this? Lars | Lars TOC_top/ru_TOC_top.lyx Lars | TOC_top files are documents with the proper language setting Lars and title | that are use to generate the corresponding TOC file. Lars | Does this answer your question? Lars Hmm... so russian is the only language to require this? No, you managed to copy only a few of the documentation files to lyx-devel: fantomas[ssh]: ll -aR lyx-devel/lib/doc/|wc -l 52 fantomas[ssh]: ll -aR lyxdoc|wc -l 126 I am not sure what happened, but many files are missing. JMarc
Re: One reason for failure of external scripts on Win32
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus The alternative is to escape 'special chars', so 'Dokumente und Angus Einstellungen' becomes 'Dokumente\ und\ Einstellungen'. This is probably more complicated and error prone. JMarc
Re: future of win32 port?
Karsten Heymann wrote: On Wed, 2 Jun 2004 11:01:24 +0200 Gour [EMAIL PROTECTED] wrote: Is there any reason why wxWidgets toolkit is (somehow) avoided? Well, I think someone would have to do it :) It's not that I'm pushing it, but, imho, it looks like a mature multi-platform toolkit with a fair licence. The more natural Toolkit for LyX would be FLTK I think, because it seems to be quite close to xforms. But that would have to be done as well... I don't think that is true any longer. The LyX core sees absolutely nothing of the GUI toolkit. All toolits are, therefore, equal. Development in the 1.3.x cycle concentrated on achieving GUI-independence and a fully functional port to the Qt toolkit. Almost everybody posting questions to the lyx-users list says that they're using the Qt frontend, so clearly the effort of porting to Qt was worthwhile. The effort of achieving GUI-indenpendence was also worthwhile because it removed a vast amount of spaghetti from the LyX kernel. Development in the 1.4.x cycle has concentrated on cleaning up the LyX kernel itself. None of the core developers have been particularly interested in contributing to the gtk frontend. That's probably because they felt that having a gtk port was less important than having a clean and maintainable kernel. I think that we've gone a long way to achieving that goal. In turn, it's made it easier to add the new features that the users will see in LyX 1.4. It makes sense to maintain two frontends, because that keeps us 'honest' to the original goal of GUI-indenpendence: clean, generic code in the core. The Qt frontend is already more powerful than the XForms one, with 'proper' support for bi-directional languages such as Hebrew. Moreover, the Qt version of CJK-LyX is both cleaner and more sophisticated. I suspect that the exciting development in the 1.5.x cycle will be full unicode support. When that happens, merging of CJK-LyX into LyX becomes practical. So, the XForms frontend will probably become the poor relation to the Qt frontend. I don't think that we have sufficient man power or motivation to change that. Instead, I think that the interest in supporting a gtk frontend will increase. The gtk toolkit has all the bells and whistles that we'll need in the future and, like Qt, is actively developed. Moreover, it's adoption will ease the adoption of LyX by Win32 users. So, should we be interested in supporting a gtk frontend in the 1.5.x cycle? IMO, yes. If development goes the way I've outlined above, then it may also make sense to consider 'retiring' the XForms frontend. Should we be interested in supporting a frontend based on Yet Another Toolkit? IMO, no. We should not waste our effort carelessly. The goal should be a more powerful tool accessible to more people. -- Angus
Re: One reason for failure of external scripts on Win32
Jean-Marc Lasgouttes wrote:
Angus The alternative is to escape 'special chars', so 'Dokumente
und Angus Einstellungen' becomes 'Dokumente\ und\ Einstellungen'.
This is probably more complicated and error prone.
Agreed. So we need:
string const subst_filename(string const input,
string const oldstr,
string const newstr)
{
return subst(input, oldstr, QuoteName(newstr));
}
That should be straightforward to do.
--
Angus
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes wrote: Rob Lahaye [EMAIL PROTECTED] writes: | autogen.sh: | Using autoconf (GNU Autoconf) 2.53 | gmake: | [...snip...] | gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src' | source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \ | depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \ | depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \ | /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c -o cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp | /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF .deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o | In file included from ../../../../boost/boost/regex/config.hpp:54, | from cpp_regex_traits.cpp:22: | ../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in | type `long' | gmake[4]: *** [cpp_regex_traits.lo] Error 1 | - | FreeBSD 4.10-STABLE i386 | GCC 3.3.4 20040505 (prerelease) [FreeBSD] Ok, it must be FreeBSD that is the problem Is uintmax_t a macro? Or uint32_t? Has inttypes.h on FreeBSD changed recently? (upgraded libc perhaps?) What is uintmax_t/uint32_t typdeffed/defined as in inttypes.h This is what I get: $ grep -n uintmax_t /usr/include/inttypes.h $ grep -n uint32_t /usr/include/inttypes.h /usr/include/inttypes.h:18:typedef __uint32_t uint32_t; Is that causing the trouble? Rob.
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Grand. Patch committed. Angus Jean-Marc, attached is the equivalent patch against 1.3.x. Angus Please add to your list of pending patches. Angus, I think you have been too fast for me there... I did not have time to tell you so, but I do not think this patch is appropriate after all. Actually, I have had a lot of interaction with Bennett Helm on the subject. That this interaction was private is certainly a bad thing and we have to change that. The situation with Qt/Mac, as I understand it, is the following: 1/ the focus problem that this patch fixes is gone with qt 3.3.x. This is good, because the 1.4.x will use that (while 1.3.x is stuck with qt 3.1 for simplicity). 2/ when giving proper parents to dialogs, they get 'always on top' behaviour, and this is not very convenient, according to Bennett's testing. 3/ the remaining problem that we had yet to solve is that (without your patch) the application menu is replaced with an empty one when a dialog has focus, which is not very intuitive for mac users. However, the qt docs states that the same menu will be used by all windows if the menubar is not attached to any window. So my plan was to tweak the qt menubar code so that the menus are not added to QMainWindow::menuBar(), but to some private menubar_ member (only for Q_WS_MAC, of course). I think this will do what we want. Then a second problem will be to make menu entries that are relevant to a document inactive when the active window is not the main window. I attach a patch I sent to Bennett to do this. Bennett old me that the patch does not work, but the intent should be clear enough. Sorry for the interference. Bennett, we should definitely continue these discussions, on lyx-devel. JMarc Index: src/frontends/qt2/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/ChangeLog,v retrieving revision 1.684 diff -u -p -r1.684 ChangeLog --- src/frontends/qt2/ChangeLog 5 May 2004 09:33:20 - 1.684 +++ src/frontends/qt2/ChangeLog 10 May 2004 13:35:37 - @@ -1,3 +1,8 @@ +2004-05-10 Jean-Marc Lasgouttes [EMAIL PROTECTED] + + * lyx_gui.C (getStatus): under Mac OS X, disable the + buffer-related lfuns when the main window does not have the focus. + 2004-05-05 Angus Leeming [EMAIL PROTECTED] * QIndexDialog.[Ch] (reject): overload the QDialog::reject function Index: src/frontends/qt2/lyx_gui.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/lyx_gui.C,v retrieving revision 1.62 diff -u -p -r1.62 lyx_gui.C --- src/frontends/qt2/lyx_gui.C 3 Apr 2004 08:37:10 - 1.62 +++ src/frontends/qt2/lyx_gui.C 10 May 2004 13:35:37 - @@ -241,6 +241,17 @@ FuncStatus getStatus(FuncRequest const default: break; } + +#ifdef Q_WS_MACX + // In LyX/Mac, when a dialog is open, the menus of the + // application can still be accessed without giving focus to + // the main window. In this case, we want to disable the menu + // entries that are buffer-related. + if (qApp-activeWindow() != qApp-mainWidget() + !lyxaction.funcHasFlag(ev.action, LyXAction::NoBuffer)) + flag.enabled(false); +#endif + return flag; }
Re: [doc] What is TOC_top/ru_TOC_top.lyx
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | Lars | Lars What is this? | Lars | Lars TOC_top/ru_TOC_top.lyx | Lars | TOC_top files are documents with the proper language setting | Lars and title | that are use to generate the corresponding TOC file. | Lars | Does this answer your question? | Lars Hmm... so russian is the only language to require this? | No, you managed to copy only a few of the documentation files to | lyx-devel: | fantomas[ssh]: ll -aR lyx-devel/lib/doc/|wc -l | 52 | fantomas[ssh]: ll -aR lyxdoc|wc -l | 126 | I am not sure what happened, but many files are missing. Somehow my lyxdoc checkout don't have all the files... I don't know why... But now... when I check: ll -aR | wc -l 121 and find . -name \*.lyx | wc 80 801313 Is this correct or am I missing 5 files. -- Lgb
Re: future of win32 port?
Angus Leeming [EMAIL PROTECTED] writes: | Should we be interested in supporting a frontend based on Yet Another | Toolkit? IMO, no. We should not waste our effort carelessly. The goal | should be a more powerful tool accessible to more people. But we won't actively hinder it. Similar to the state gtk is in now really, there is not active development (only on/off once in a while updates), and if something is easy to fix there we do it, but we do not care a lot if it breaks completely. -- Lgb
Re: future of win32 port?
Hello Gour, On Wed, 2 Jun 2004 13:15:07 +0200 Gour [EMAIL PROTECTED] wrote: Karsten Heymann ([EMAIL PROTECTED]) wrote: The more natural Toolkit for LyX would be FLTK I think, because it seems to be quite close to xforms. But that would have to be done as well... Why do you think it is more 'natural'? Since LyX is going into GUI-independence territory, can we say that some toolkit is 'more natural'? quote http://www.mail-archive.com/[EMAIL PROTECTED]/msg60374.html Of course, if the xforms code were ported to FLTK, we could have two identical frontends. Then there might be a case to argue. Would that make sense (i.e. shipping code with two near identical frontends)? I mean, do you want to include every frontend for which you have volunteers? As fltk is, as I understand it, more or less an improved xforms, I would not mind if fltk played the Darwin game with xforms (though xforms works well enough where I need it , i.e. on slow machines like my old notebook). /quote But maybe I'm wrong here, since I'm no programmer (only latex and python, if that counts ;-) ) Karsten
Re: boost/cstdint.hpp:121: error
Rob Lahaye [EMAIL PROTECTED] writes:
Ok, it must be FreeBSD that is the problem
Is uintmax_t a macro? Or uint32_t?
Has inttypes.h on FreeBSD changed recently?
(upgraded libc perhaps?)
What is uintmax_t/uint32_t typdeffed/defined as in inttypes.h
| This is what I get:
| $ grep -n uintmax_t /usr/include/inttypes.h
| $ grep -n uint32_t /usr/include/inttypes.h
| /usr/include/inttypes.h:18:typedef __uint32_t uint32_t;
| Is that causing the trouble?
Not directly. This compiles:
typedef long tull;
typedef tull tall;
int main()
{}
Where does __uint32_t come from?
--
Lgb
Re: [doc] What is TOC_top/ru_TOC_top.lyx
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Somehow my lyxdoc checkout don't have all the files... Lars I don't know why... Lars But now... when I check: Lars ll -aR | wc -l 121 Lars and Lars find . -name \*.lyx | wc 80 80 1313 Lars Is this correct or am I missing 5 files. In which directories? There a several non-lyx files in lyxdoc: fantomas[ssh]: ls -r | grep -v '\.lyx$' TOC_top README.Documentation platypus.eps mobius.eps Makefile.depend Makefile escher-lsd.eps Doc_toc.pl Depend.pl CVS ChangeLog So that's 9 non-lyx files. Does that answer your question? JMarc
Cygwin lyx compile failure
Anyone have any ideas about this? Strangely, this is only happening on one
of my Cygwin systems.
make install-recursive
make[5]: Entering directory `/home/ksylvan/src/lyx-build/src/frontends/xforms'
Making install in forms
make[6]: Entering directory `/home/ksylvan/src/lyx-build/src/frontends/xforms/forms'
{ [ ../../../../../lyx/src/frontends/xforms/forms != . ] [ ! -a form_aboutlyx.fd ]
ln -s ../../../../../lyx/src/frontends/xforms/forms/form_aboutlyx.fd . ; } || true
[: form_aboutlyx.fd: unknown operand
/bin/sh ../../../../../lyx/src/frontends/xforms/forms/fdfix.sh `basename
../../../../../lyx/src/frontends/xforms/forms/form_aboutlyx.fd`
Input file does not exist. Cannot continue
make[6]: *** [form_aboutlyx.C] Error 1
make[6]: Leaving directory `/home/ksylvan/src/lyx-build/src/frontends/xforms/forms'
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: [doc] What is TOC_top/ru_TOC_top.lyx
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | fantomas[ssh]: ls -r | grep -v '\.lyx$' | TOC_top missing | README.Documentation missing | platypus.eps missing | mobius.eps missing | Makefile.depend is this really in lyxdoc at all? | Makefile missing, cannot just copy | escher-lsd.eps missing | Doc_toc.pl missing | Depend.pl missing | CVS not a file | ChangeLog copied | So that's 9 non-lyx files. | Does that answer your question? kindo -- Lgb
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Jean-Marc Lasgouttes wrote: Angus, I think you have been too fast for me there... I did not have time to tell you so, but I do not think this patch is appropriate after all. Then I'll revert it this evening. 1/ the focus problem that this patch fixes is gone with qt 3.3.x. This is good, because the 1.4.x will use that (while 1.3.x is stuck with qt 3.1 for simplicity). Good. Note that this focus thing is not confined to the Mac. The change worked also under linux. I take it that qt 3.3.x does the right thing for all supported OSes? 2/ when giving proper parents to dialogs, they get 'always on top' behaviour, and this is not very convenient, according to Bennett's testing. Agreed. 3/ the remaining problem that we had yet to solve is that (without your patch) the application menu is replaced with an empty one when a dialog has focus, which is not very intuitive for mac users. However, the qt docs states that the same menu will be used by all windows if the menubar is not attached to any window. So my plan was to tweak the qt menubar code so that the menus are not added to QMainWindow::menuBar(), but to some private menubar_ member (only for Q_WS_MAC, of course). I think this will do what we want. Clever. Then a second problem will be to make menu entries that are relevant to a document inactive when the active window is not the main window. I attach a patch I sent to Bennett to do this. Bennett old me that the patch does not work, but the intent should be clear enough. One thing that we have talked about in the past is a LyX-widget that would enable the user to input data in a dialog yet retain the same interface as the lyx screen. Such a dialog-independent menubar might be useful in that case. Sorry for the interference. No interference. I was just looking through bugzilla and addressing those bugs that I could. Bennett, we should definitely continue these discussions, on lyx-devel. -- Angus
Re: future of win32 port?
Lars Gullik Bjnnes ([EMAIL PROTECTED]) wrote: I'd say that a C++ toolkit is more natural, other than that it really doesn't matter... One more point. Although I know that the choice of GUI toolkit is evoking religious war, I'm just thinking that at the present moment there are (maybe) separate endeavours for each port (are they?), while wxWidgets can (in theory) provide port(s) for three platforms with native widgets on each. However, I don't want to push LyX developers in something which they do not consider as a fun :-) Thank You for your efforts and providing present LyX (which is enough for me :-) Sincerely, Gour -- Gour| [EMAIL PROTECTED] Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Re: [doc] What is TOC_top/ru_TOC_top.lyx
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars | Makefile.depend Lars is this really in lyxdoc at all? No, it is autogenerated by a ad-hoc dependency tracking mechanism. JMarc
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc Lasgouttes wrote: Angus, I think you have been too fast for me there... I did not have time to tell you so, but I do not think this patch is appropriate after all. Angus Then I'll revert it this evening. Thanks. 1/ the focus problem that this patch fixes is gone with qt 3.3.x. This is good, because the 1.4.x will use that (while 1.3.x is stuck with qt 3.1 for simplicity). Angus Good. Note that this focus thing is not confined to the Mac. Angus The change worked also under linux. I take it that qt 3.3.x Angus does the right thing for all supported OSes? Did you notice a difference with your patch? I did not see any. I think this will do what we want. Angus Clever. Time will tell :) JMarc
Re: Cygwin lyx compile failure
Kayvan A. Sylvan [EMAIL PROTECTED] writes: | Anyone have any ideas about this? Strangely, this is only happening on one | of my Cygwin systems. have you tried a clean distclean maintianerclean to see if that helps? Or are there different versions of cygwin? -- Lgb
Re: Cygwin lyx compile failure
Kayvan A. Sylvan wrote:
Anyone have any ideas about this? Strangely, this is only happening
on one of my Cygwin systems.
{ [ ../../../../../lyx/src/frontends/xforms/forms != . ]
[ ! -a form_aboutlyx.fd ]
[: form_aboutlyx.fd: unknown operand
Lars has added this bit of magic recently to xforms/forms/Makefile.am:
.fd.C: $(srcdir)/fdfix.sh $(srcdir)/fdfix[ch].sed
$(srcdir)/tmp_str.sed
{ [ $(srcdir) != . ] [ ! -a $(F) ] $(LN_S) $ . ; } || true
$(SHELL) $(SCRIPT) `basename $`
What he's trying to do is copy the .fd file from the src directory to
the build directory so that 'fdesign' can be run 'in place'.
My copy of 'unix in a nutshell' tells me that 'test -a' is specific
to ksh, so this is going to break on systems where sh means sh, not
bash.
So, my guess is that you have builddir != srcdir and the creation of
the symbolic link has failed.
Incidentally, why use both $(F) and `basename $`. They;re
equivalent, aren't they?
/bin/sh ../../../../../lyx/src/frontends/xforms/forms/fdfix.sh
`basename
../../../../../lyx/src/frontends/xforms/forms/form_aboutlyx.fd`
Input file does not exist. Cannot continue make[6]: ***
[form_aboutlyx.C] Error 1 make[6]: Leaving directory
`/home/ksylvan/src/lyx-build/src/frontends/xforms/forms'
--
Angus
Re: future of win32 port?
Angus Leeming ([EMAIL PROTECTED]) wrote: So, should we be interested in supporting a gtk frontend in the 1.5.x cycle? IMO, yes. If development goes the way I've outlined above, then it may also make sense to consider 'retiring' the XForms frontend. Should we be interested in supporting a frontend based on Yet Another Toolkit? IMO, no. We should not waste our effort carelessly. The goal should be a more powerful tool accessible to more people. My point in bringing the wxWidgets question was just that - to have one toolkit with potential to bring LyX (almost automatically) to three main platforms: Linux, Mac Win32, instead of having devlopers working on each port separately - saving the developer time. Besides that, wxWidgets seems more stable than GTK on win32 and give native widgets, and gives, imho, enough bells whistles too. Sincerely, Gour -- Gour| [EMAIL PROTECTED] Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Re: boost/cstdint.hpp:121: error
On Wed, Jun 02, 2004 at 12:56:24PM +0200, Lars Gullik Bj?nnes wrote: Ok, it must be FreeBSD that is the problem No, I have recently started seeing a very similar problem on Linux. /usr/local/gcc-cvs/bin/g++ -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -g -W -Wall -c convenience.cpp -MT convenience.lo -MD -MP -MF .deps/convenience.TPlo -o convenience.o In file included from ../../../../boost/boost/config.hpp:35, from ../../../../boost/boost/filesystem/config.hpp:18, from ../../../../boost/boost/filesystem/path.hpp:15, from ../../../../boost/boost/filesystem/convenience.hpp:16, from convenience.cpp:17: ../../../../boost/boost/config/compiler/gcc.hpp:92:7: warning: #warning Unknown compiler version - please run the configure tests and report the results In file included from /usr/local/gcc-cvs/lib/gcc/i686-pc-linux-gnu/3.5.0/../../../../include/c++/3.5.0/cstdlib:50, from ../../../../boost/boost/config/platform/linux.hpp:14, from ../../../../boost/boost/config.hpp:53, from ../../../../boost/boost/filesystem/config.hpp:18, from ../../../../boost/boost/filesystem/path.hpp:15, from ../../../../boost/boost/filesystem/convenience.hpp:16, from convenience.cpp:17: /usr/local/gcc-cvs/lib/gcc/i686-pc-linux-gnu/3.5.0/../../../../include/c++/3.5.0/cstddef:52: error: expected unqualified-id before long /usr/local/gcc-cvs/lib/gcc/i686-pc-linux-gnu/3.5.0/../../../../include/c++/3.5.0/cstddef:52: error: expected `;' before long /usr/local/gcc-cvs/lib/gcc/i686-pc-linux-gnu/3.5.0/../../../../include/c++/3.5.0/cstddef:52: error: declaration does not declare anything The system has not changed. john
Re: future of win32 port?
Gour wrote: Lars Gullik Bjønnes ([EMAIL PROTECTED]) wrote: I'd say that a C++ toolkit is more natural, other than that it really doesn't matter... One more point. Although I know that the choice of GUI toolkit is evoking religious war, I don't think so. The Qt frontend exists, so we support it. The gtk, wxWidgets, gnome, MSFC frontends do not, so we don't. If someone wants to write a frontend using these toolkits, then great, but I don't see any of the current team being motivated to help actively. I'm just thinking that at the present moment there are (maybe) separate endeavours for each port (are they?), while wxWidgets can (in theory) provide port(s) for three platforms with native widgets on each. The Qt toolkit is cross platform and the frontend works. We'll keep it working. It's up to you to decide whether you want to help port lyx to another toolkit. -- Angus
Re: boost/cstdint.hpp:121: error
John Levon [EMAIL PROTECTED] writes: | On Wed, Jun 02, 2004 at 12:56:24PM +0200, Lars Gullik Bj?nnes wrote: Ok, it must be FreeBSD that is the problem | No, I have recently started seeing a very similar problem on Linux. Completely different you mean... | /usr/local/gcc-cvs/bin/g++ -DHAVE_CONFIG_H -I. -I. -I../../../../src | -I../../../../boost -I/usr/X11R6/include | -DBOOST_USER_CONFIG=config.h -g -W -Wall -c convenience.cpp -MT | convenience.lo -MD -MP -MF .deps/convenience.TPlo -o convenience.o | In file included from ../../../../boost/boost/config.hpp:35, | from ../../../../boost/boost/filesystem/config.hpp:18, | from ../../../../boost/boost/filesystem/path.hpp:15, | from | ../../../../boost/boost/filesystem/convenience.hpp:16, | from convenience.cpp:17: | ../../../../boost/boost/config/compiler/gcc.hpp:92:7: warning: #warning | Unknown compiler version - please run the configure tests and report | the results Please update gcc.hpp when reporting about gcc 3.5 | In file included from | /usr/local/gcc-cvs/lib/gcc/i686-pc-linux-gnu/3.5.0/../../../../include/c++/3.5.0/cstdlib:50, | from | ../../../../boost/boost/config/platform/linux.hpp:14, | from ../../../../boost/boost/config.hpp:53, | from ../../../../boost/boost/filesystem/config.hpp:18, | from ../../../../boost/boost/filesystem/path.hpp:15, | from | ../../../../boost/boost/filesystem/convenience.hpp:16, | from convenience.cpp:17: | /usr/local/gcc-cvs/lib/gcc/i686-pc-linux-gnu/3.5.0/../../../../include/c++/3.5.0/cstddef:52: | error: expected unqualified-id before long | /usr/local/gcc-cvs/lib/gcc/i686-pc-linux-gnu/3.5.0/../../../../include/c++/3.5.0/cstddef:52: | error: expected `;' before long | /usr/local/gcc-cvs/lib/gcc/i686-pc-linux-gnu/3.5.0/../../../../include/c++/3.5.0/cstddef:52: | error: declaration does not declare anything | The system has not changed. Sure it did. Or do you have a goblin in your box? (you installed gcc 3.5 right? But I don't see these errors with 3.5...) Besides this is completely different from the error seen on FreeBSD. -- Lgb
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Jean-Marc Lasgouttes wrote: Angus Good. Note that this focus thing is not confined to the Mac. Angus The change worked also under linux. I take it that qt 3.3.x Angus does the right thing for all supported OSes? Did you notice a difference with your patch? I did not see any. Yes. I followed the prescription outlined in the bug report. Without the patch, keyboard input went to the lyx screen. With the patch, it went to the index dialog. -- Angus
[PATCH] Find locales properly in Qt/Mac
This patch adds code for LyX/Mac to find its locale files correctly
and changes the default user directory from .lyx to
~/Library/Preferences/LyX (for Qt/Mac too).
Lars, this changes some of your code in message.C. Is it OK with you?
JMarc
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.1922
diff -u -p -r1.1922 ChangeLog
--- src/ChangeLog 1 Jun 2004 17:54:33 - 1.1922
+++ src/ChangeLog 2 Jun 2004 13:39:55 -
@@ -1,3 +1,13 @@
+2004-05-10 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * lyxrc.C: do not set user_email to a default value but use empty
+ instead. The entry used to be translated, which does not work
+ since at the point where lyxrc is constructed there is not
+ translation service available
+
+ * messages.C (getLocaleDir): remove and use directly
+ lyx_localedir() instead
+
2004-06-01 Angus Leeming [EMAIL PROTECTED]
* output_linuxdoc.C (linuxdocParagraphs): Check that the paragraph
Index: src/lyxrc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxrc.C,v
retrieving revision 1.173
diff -u -p -r1.173 lyxrc.C
--- src/lyxrc.C 20 Apr 2004 08:51:10 - 1.173
+++ src/lyxrc.C 2 Jun 2004 13:39:56 -
@@ -272,9 +272,6 @@ void LyXRC::setDefaults() {
user_name = lyx::support::user_name();
user_email = lyx::support::user_email();
-
- if (user_email.empty())
- user_email = _(email address unknown);
}
Index: src/messages.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/messages.C,v
retrieving revision 1.15
diff -u -p -r1.15 messages.C
--- src/messages.C 6 Oct 2003 15:42:29 - 1.15
+++ src/messages.C 2 Jun 2004 13:39:56 -
@@ -21,21 +21,6 @@ using std::string;
#ifdef ENABLE_NLS
-namespace {
-
-string const getLocaleDir()
-{
- static string locale_dir;
-
- if (locale_dir.empty()) {
- locale_dir = GetEnvPath(LYX_LOCALEDIR);
- if (locale_dir.empty())
- locale_dir = lyx_localedir();
- }
- return locale_dir;
-}
-
-} // anon namespace
#if 0
@@ -55,7 +40,7 @@ public:
//lyxerr Messages: language( l
//) in dir( dir ) std::endl;
- cat_gl = mssg_gl.open(PACKAGE, loc_gl, getLocaleDir().c_str());
+ cat_gl = mssg_gl.open(PACKAGE, loc_gl, lyx_localedir().c_str());
}
@@ -99,8 +84,6 @@ public:
//lyxerr Messages: language( l
//) in dir( dir ) std::endl;
- bindtextdomain(PACKAGE, getLocaleDir().c_str());
- textdomain(PACKAGE);
}
~Pimpl() {}
@@ -112,6 +95,8 @@ public:
char * old = strdup(setlocale(LC_ALL, 0));
char * n = setlocale(LC_ALL, lang_.c_str());
+ bindtextdomain(PACKAGE, lyx_localedir().c_str());
+ textdomain(PACKAGE);
const char* msg = gettext(m.c_str());
setlocale(LC_ALL, old);
free(old);
Index: src/support/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v
retrieving revision 1.254
diff -u -p -r1.254 ChangeLog
--- src/support/ChangeLog 27 May 2004 07:41:51 - 1.254
+++ src/support/ChangeLog 2 Jun 2004 13:39:56 -
@@ -1,3 +1,11 @@
+2004-05-04 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * path_defines.C.in (setLyxPaths): make sure that LyX/Mac can find
+ its po files when moved around; set default user directory to
+ ~/Library/Preferences/LyX/ for LyX/Mac.
+ (lyx_localedir): return the value that may have been computed in
+ setLyXPaths
+
2004-05-27 Kayvan Sylvan [EMAIL PROTECTED]
* Makefile.am (libsupport_la_SOURCES): remove reference to
Index: src/support/path_defines.C.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/path_defines.C.in,v
retrieving revision 1.11
diff -u -p -r1.11 path_defines.C.in
--- src/support/path_defines.C.in 27 Apr 2004 12:48:45 - 1.11
+++ src/support/path_defines.C.in 2 Jun 2004 13:39:56 -
@@ -40,6 +40,8 @@ string build_lyxdir_;
// Store for the path to the user-level support files.
string user_lyxdir_;
+// Store for the path to the locale directory.
+string localedir_;
/* The absolute path to the system-level lyx support files.
* (Make-time value.)
@@ -73,7 +75,10 @@ string const top_srcdir()
string const lyx_localedir()
{
static string const ll = %LOCALEDIR%;
- return ll;
+ if (localedir_.empty())
+ return ll;
+ else
+ return localedir_;
}
@@ -287,6 +292,15 @@ bool setLyxPaths()
lyxerr[Debug::INIT] System directory: '
system_lyxdir_ '\'' endl;
+ // This is true when we are running from a Mac OS X bundle
+ // (for LyX/Mac)
+ bool const inOSXBundle =
+ system_lyxdir_ == NormalizePath(AddPath(binpath, ../Resources/)
+ + OnlyFilename(binname));
+ if (inOSXBundle)
+ lyxerr[Debug::INIT] Running from LyX/Mac bundle.
+ endl;
+
//
// Set PATH for LyX/Mac
//
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc Lasgouttes wrote: Good. Note that this focus thing is Angus not confined to the Mac. The change worked also under linux. I Angus take it that qt 3.3.x does the right thing for all supported Angus OSes? Did you notice a difference with your patch? I did not see any. Angus Yes. I followed the prescription outlined in the bug report. Angus Without the patch, keyboard input went to the lyx screen. With Angus the patch, it went to the index dialog. And does it give you a 'stay on top' behaviour? Which qt version do you have? JMarc
Re: Cygwin lyx compile failure
Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | My copy of 'unix in a nutshell' tells me that 'test -a' is | specific to ksh, so this is going to break on systems where sh | means sh, not bash. So I can use -e instead? Not if you want plain old 'sh' to understand you. Both these seem to work: # your_symbolic_link exists and is a regular file test -f your_symbolic_link ... # your symbolic_link exists and is readable test -r your_symbolic_link ... I guess the '-r' version has the semantics you're looking for. | So, my guess is that you have builddir != srcdir and the creation | of the symbolic link has failed. | Incidentally, why use both $(F) and `basename $`. They;re | equivalent, aren't they? Could be that I learned abougt $(F) after I had written the line below... Sorry, I didn't mean to be rude. I've only just learned about $(F) myself, having pulled 'unix in a nutshell' in an attempt to understand your code. -- Angus
Re: boost/cstdint.hpp:121: error
On Wed, Jun 02, 2004 at 03:37:52PM +0200, Lars Gullik Bj?nnes wrote: Sure it did. Or do you have a goblin in your box? (you installed gcc 3.5 right? But I don't see these errors with 3.5...) I previously compiled CVS lyx fine with the same GCC version. A cvs update then caused it to fail. Besides this is completely different from the error seen on FreeBSD. Are you sure? The error reporting machinery is of course very different between the CVS versions. Seems a cooincidence at least if it really is a different problem. john
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc Lasgouttes wrote: Good. Note that this focus thing is Angus not confined to the Mac. The change worked also under linux. I Angus take it that qt 3.3.x does the right thing for all supported Angus OSes? Did you notice a difference with your patch? I did not see any. Angus Yes. I followed the prescription outlined in the bug report. Angus Without the patch, keyboard input went to the lyx screen. With Angus the patch, it went to the index dialog. And does it give you a 'stay on top' behaviour? I don't know. The machine I tested on is at home and I'm not ;-) I'll play further this evening. Which qt version do you have? Whatever comes with Fedora 1. Qt 3.2? -- Angus
Re: [PATCH] Find locales properly in Qt/Mac
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| This patch adds code for LyX/Mac to find its locale files correctly
| and changes the default user directory from .lyx to
| ~/Library/Preferences/LyX (for Qt/Mac too).
| Lars, this changes some of your code in message.C. Is it OK with you?
It might be
I am not overly fond of the inOSXbundle stuff.
| JMarc
| Index: src/ChangeLog
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
| retrieving revision 1.1922
| diff -u -p -r1.1922 ChangeLog
| --- src/ChangeLog 1 Jun 2004 17:54:33 - 1.1922
| +++ src/ChangeLog 2 Jun 2004 13:39:55 -
| @@ -1,3 +1,13 @@
| +2004-05-10 Jean-Marc Lasgouttes [EMAIL PROTECTED]
| +
| + * lyxrc.C: do not set user_email to a default value but use empty
| + instead. The entry used to be translated, which does not work
| + since at the point where lyxrc is constructed there is not
| + translation service available
| +
| + * messages.C (getLocaleDir): remove and use directly
| + lyx_localedir() instead
| +
| 2004-06-01 Angus Leeming [EMAIL PROTECTED]
|
| * output_linuxdoc.C (linuxdocParagraphs): Check that the paragraph
| Index: src/messages.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/messages.C,v
| retrieving revision 1.15
| diff -u -p -r1.15 messages.C
| --- src/messages.C6 Oct 2003 15:42:29 - 1.15
| +++ src/messages.C2 Jun 2004 13:39:56 -
| @@ -99,8 +84,6 @@ public:
| //lyxerr Messages: language( l
| //) in dir( dir ) std::endl;
|
| - bindtextdomain(PACKAGE, getLocaleDir().c_str());
| - textdomain(PACKAGE);
| }
|
| ~Pimpl() {}
| @@ -112,6 +95,8 @@ public:
|
| char * old = strdup(setlocale(LC_ALL, 0));
| char * n = setlocale(LC_ALL, lang_.c_str());
| + bindtextdomain(PACKAGE, lyx_localedir().c_str());
| + textdomain(PACKAGE);
Why the move?
| const char* msg = gettext(m.c_str());
| setlocale(LC_ALL, old);
| free(old);
| Index: src/support/ChangeLog
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v
| retrieving revision 1.254
| diff -u -p -r1.254 ChangeLog
| --- src/support/ChangeLog 27 May 2004 07:41:51 - 1.254
| +++ src/support/ChangeLog 2 Jun 2004 13:39:56 -
| @@ -1,3 +1,11 @@
| +2004-05-04 Jean-Marc Lasgouttes [EMAIL PROTECTED]
| +
| + * path_defines.C.in (setLyxPaths): make sure that LyX/Mac can find
| + its po files when moved around; set default user directory to
| + ~/Library/Preferences/LyX/ for LyX/Mac.
| + (lyx_localedir): return the value that may have been computed in
| + setLyXPaths
| +
| 2004-05-27 Kayvan Sylvan [EMAIL PROTECTED]
|
| * Makefile.am (libsupport_la_SOURCES): remove reference to
| Index: src/support/path_defines.C.in
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/path_defines.C.in,v
| retrieving revision 1.11
| diff -u -p -r1.11 path_defines.C.in
| --- src/support/path_defines.C.in 27 Apr 2004 12:48:45 - 1.11
| +++ src/support/path_defines.C.in 2 Jun 2004 13:39:56 -
| @@ -40,6 +40,8 @@ string build_lyxdir_;
| // Store for the path to the user-level support files.
| string user_lyxdir_;
|
| +// Store for the path to the locale directory.
| +string localedir_;
|
| /* The absolute path to the system-level lyx support files.
| * (Make-time value.)
| @@ -73,7 +75,10 @@ string const top_srcdir()
| string const lyx_localedir()
| {
| static string const ll = %LOCALEDIR%;
| - return ll;
| + if (localedir_.empty())
| + return ll;
| + else
| + return localedir_;
| }
Is the else needed?
|
|
| @@ -287,6 +292,15 @@ bool setLyxPaths()
| lyxerr[Debug::INIT] System directory: '
|system_lyxdir_ '\'' endl;
|
| + // This is true when we are running from a Mac OS X bundle
| + // (for LyX/Mac)
| + bool const inOSXBundle =
| + system_lyxdir_ == NormalizePath(AddPath(binpath, ../Resources/)
| + + OnlyFilename(binname));
| + if (inOSXBundle)
| + lyxerr[Debug::INIT] Running from LyX/Mac bundle.
| + endl;
This should not be runtime...
We know when we compile if we are in OSX or not.
| +
| //
| // Set PATH for LyX/Mac
| // LyX/Mac is a relocatable application bundle; here we add to
| @@ -295,14 +309,32 @@ bool setLyxPaths()
| // needs to run latex, previewers, etc.
| //
|
| - if (system_lyxdir_ ==
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Jean-Marc Lasgouttes wrote: Angus Good. Note that this focus thing is not confined to the Mac. Angus The change worked also under linux. I take it that qt 3.3.x Angus does the right thing for all supported OSes? Did you notice a difference with your patch? I did not see any. Yes. I followed the prescription outlined in the bug report. Without the patch, keyboard input went to the lyx screen. With the patch, it went to the index dialog. I've tried the patch on LyX/Mac. While it doesn't seem to affect the focus issue (which, as Jean-Marc noted, is not a problem with qt-3.3.x), it does change dialogs to be always on top -- to be modal -- which is not desirable on the Mac, at least. Bennett
Re: Cygwin lyx compile failure
Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | My copy of 'unix in a nutshell' tells me that 'test -a' is | specific to ksh, so this is going to break on systems where sh | means sh, not bash. So I can use -e instead? | Not if you want plain old 'sh' to understand you. Does old 'sh' has a test built-in? | Both these seem to work: | # your_symbolic_link exists and is a regular file | test -f your_symbolic_link ... | # your symbolic_link exists and is readable | test -r your_symbolic_link ... -r has nothing in particular to do with symbolic links has it? | I guess the '-r' version has the semantics you're looking for. seems so from man test as well. | So, my guess is that you have builddir != srcdir and the creation | of the symbolic link has failed. | Incidentally, why use both $(F) and `basename $`. They;re | equivalent, aren't they? Could be that I learned abougt $(F) after I had written the line below... | Sorry, I didn't mean to be rude. I've only just learned about $(F) | myself, having pulled 'unix in a nutshell' in an attempt to | understand your code. Hmm... did I sound rudeed, not intentional. (As in Are you rud(e)ing me? aka. Are you being rude to me?) -- Lgb
Re: boost/cstdint.hpp:121: error
John Levon [EMAIL PROTECTED] writes: | On Wed, Jun 02, 2004 at 03:37:52PM +0200, Lars Gullik Bj?nnes wrote: Sure it did. Or do you have a goblin in your box? (you installed gcc 3.5 right? But I don't see these errors with 3.5...) | I previously compiled CVS lyx fine with the same GCC version. A cvs | update then caused it to fail. of gcc or lyx? nothing in lyx/boost changed... automake/autoconf differences? Besides this is completely different from the error seen on FreeBSD. | Are you sure? The error reporting machinery is of course very different | between the CVS versions. Seems a cooincidence at least if it really is | a different problem. Your is some syntax problem, the one on FreeBSD is redefinition of a type. -- Lgb
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Bennett Helm wrote:
Jean-Marc Lasgouttes wrote:
Angus Good. Note that this focus thing is not confined to the
Mac. Angus The change worked also under linux. I take it that qt
3.3.x Angus does the right thing for all supported OSes?
Did you notice a difference with your patch? I did not see any.
Yes. I followed the prescription outlined in the bug report.
Without the patch, keyboard input went to the lyx screen. With the
patch, it went to the index dialog.
I've tried the patch on LyX/Mac. While it doesn't seem to affect the
focus issue (which, as Jean-Marc noted, is not a problem with
qt-3.3.x), it does change dialogs to be always on top -- to be modal
-- which is not desirable on the Mac, at least.
I'm not disputing your observations, but I do find them surprising.
The Qt docs for Qt 3.2 state:
Member Function Documentation
explicit QDialog::QDialog ( QWidget * parent = 0, const char * name =
0, bool modal = FALSE, WFlags f = 0 ) Constructs a dialog called
name, with parent parent.
A dialog is always a top-level widget, but if it has a parent, its
default location is centered on top of the parent. It will also share
the parent's taskbar entry.
The widget flags f are passed on to the QWidget constructor. If, for
example, you don't want a What's This button in the titlebar of the
dialog, pass WStyle_Customize | WStyle_NormalBorder | WStyle_Title |
WStyle_SysMenu in f.
Warning: In Qt 3.2, the modal flag is obsolete. There is now a
setModal() function that can be used for obtaining a modal behavior
when calling show(). This is rarely needed, because modal dialogs are
usually invoked using exec(), which ignores the modal flag.
So, it seems to me that the parent thingy is meant to be orthogonal
to the modal thingy. What happens if you change QDialogView::show():
void QDialogView::show()
{
if (!form()) {
build();
}
form()-setMinimumSize(form()-sizeHint());
update(); // make sure its up-to-date
form()-setCaption(toqstr(getTitle()));
if (form()-isVisible()) {
form()-raise();
} else {
+ if (form()-isModal()) {
+ lyxerr Wow! Modal dialog! std::endl;
+ form()-setModal(false);
+ }
form()-show();
}
}
--
Angus
Re: future of win32 port?
Angus Leeming ([EMAIL PROTECTED]) wrote: Hi Angus! The Qt toolkit is cross platform and the frontend works. We'll keep it working. It's up to you to decide whether you want to help port lyx to another toolkit. The whole thread has started (see the subject) with the question of win32 port. Qt is not free for win32 and therefore further development is stalled, and my initial point in bringing wxWidgets as a free cross-platform toolkit was with the idea to solve the future of win32 port as a mean of further propagation of LyX LaTeX/TeX typesetting in a win32 world which still has a great majority of users. Otherwise I'm happy running LyX (1.3.4 with qt front-end :-) on my Gentoo box and do not have personal interest in win32 port. Moreover, being not able to offer some concrete help in realizing it, it's better to resist from further discussion. Thank you for your input. Sincerely, Gour -- Gour| [EMAIL PROTECTED] Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Re: future of win32 port?
Angus Leeming wrote: The more natural Toolkit for LyX would be FLTK I think, because it seems to be quite close to xforms. But that would have to be done as well... I don't think that is true any longer. The LyX core sees absolutely nothing of the GUI toolkit. All toolits are, therefore, equal. Incidentally, Angus: Since xforms was the base of fltk, it aims to be highly compatible to xforms (synonymous functions etc.). It even provides a tool for converting *.fd files to fltk dialogs. Do you know if this statement is still true for xforms 1.x? Just curious. Regards, Jürgen
Re: future of win32 port?
Gour wrote: Qt is not free for win32 and therefore further development is stalled, and my initial point in bringing wxWidgets as a free cross-platform toolkit was with the idea to solve the future of win32 port as a mean of further propagation of LyX LaTeX/TeX typesetting in a win32 world which still has a great majority of users. Perhaps there's some vague hope, although the development of this seems to be very slow: http://kde-cygwin.sourceforge.net/qt3-win32/ Jürgen.
Re: Cygwin lyx compile failure
Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | My copy of 'unix in a nutshell' tells me that 'test -a' is | specific to ksh, so this is going to break on systems where sh | means sh, not bash. So I can use -e instead? | Not if you want plain old 'sh' to understand you. Does old 'sh' has a test built-in? No, the bourne shell uses /bin/test. test -f file ... [ -f file ] ... are equivalent. Is that what you mean? | Both these seem to work: | # your_symbolic_link exists and is a regular file | test -f your_symbolic_link ... | # your symbolic_link exists and is readable | test -r your_symbolic_link ... -r has nothing in particular to do with symbolic links has it? No, but you want to test whether you can make a symbolic link. Ie, whether there is something in the way. It seems that there is also -L file True if file exists and is a symbolic link. but my book explicitly says that this is a ksh-ism. | Incidentally, why use both $(F) and `basename $`. They;re | equivalent, aren't they? Could be that I learned abougt $(F) after I had written the line below... | Sorry, I didn't mean to be rude. I've only just learned about | $(F) myself, having pulled 'unix in a nutshell' in an attempt to | understand your code. Hmm... did I sound rudeed, not intentional. (As in Are you rud(e)ing me? aka. Are you being rude to me?) I think you need a beer ;-) -- Angus
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Angus == Angus Leeming [EMAIL PROTECTED] writes: I've tried the patch on LyX/Mac. While it doesn't seem to affect the focus issue (which, as Jean-Marc noted, is not a problem with qt-3.3.x), it does change dialogs to be always on top -- to be modal -- which is not desirable on the Mac, at least. Angus I'm not disputing your observations, but I do find them Angus surprising. The Qt docs for Qt 3.2 state: To modulate a bit Bennett's claim (as far as I understand his previous descriptions to me): the patch adds a stay-on-top behaviour to dialogs (I just checked that it happens on linux too), not modality (which would be to block the interface of the window below). It may be that the two are the same with Aqua, for focus policy reasons. JMarc
Re: Cygwin lyx compile failure
Angus Leeming [EMAIL PROTECTED] writes: Does old 'sh' has a test built-in? | No, the bourne shell uses /bin/test. | test -f file ... | [ -f file ] ... | are equivalent. Is that what you mean? No, I just thought that /bin/test had '-e', but I use '-r' instead in the what I checked in. | Both these seem to work: | # your_symbolic_link exists and is a regular file | test -f your_symbolic_link ... | # your symbolic_link exists and is readable | test -r your_symbolic_link ... -r has nothing in particular to do with symbolic links has it? | No, but you want to test whether you can make a symbolic link. Ie, | whether there is something in the way. Not really, I only want to know if there is a file there, I don't care what kind of file it is. Hmm... did I sound rudeed, not intentional. (As in Are you rud(e)ing me? aka. Are you being rude to me?) | I think you need a beer ;-) so very true... I'll get myself a 6-pack a bit later... -- Lgb
Re: future of win32 port?
Juergen Spitzmueller wrote: Incidentally, Angus: Since xforms was the base of fltk, it aims to be highly compatible to xforms (synonymous functions etc.). It even provides a tool for converting *.fd files to fltk dialogs. Do you know if this statement is still true for xforms 1.x? Just curious. Given that the XForms API is essentially unchanged since version 0.89, then I guess so. However, fltk version 2 no longer aims to provide this compatibility. -- Angus
Re: [PATCH] Find locales properly in Qt/Mac
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| Lars, this changes some of your code in message.C. Is it OK with you?
Lars It might be
Lars I am not overly fond of the inOSXbundle stuff.
OK, let's see...
Lars | char * old = strdup(setlocale(LC_ALL, 0)); | char * n =
Lars setlocale(LC_ALL, lang_.c_str()); | + bindtextdomain(PACKAGE,
Lars lyx_localedir().c_str()); | + textdomain(PACKAGE);
Lars Why the move?
Because the localedir needs to be changes _after_ the Message object
has been created (which happens at startup). Maybe we could have a
Message::updateLocaleDir method or something to signal this kind of
thing, but it is not satisfactory either.
Lars @@ -73,7 +75,10 @@ string const
Lars top_srcdir() | string const lyx_localedir() | { | static
Lars string const ll = %LOCALEDIR%; | - return ll; | + if
Lars (localedir_.empty()) | + return ll; | + else | + return
Lars localedir_;
Lars | }
Lars Is the else needed?
It means: ``if we have an explicit localedir_, use it, else use the
static value''. I am not sure I understand the question.
Lars | + // This is true when we are running from a Mac OS X bundle |
Lars + // (for LyX/Mac) | + bool const inOSXBundle = | +
Lars system_lyxdir_ == NormalizePath(AddPath(binpath,
Lars ../Resources/) | + + OnlyFilename(binname)); | + if
Lars (inOSXBundle) | + lyxerr[Debug::INIT] Running from LyX/Mac
Lars bundle. | + endl;
Lars This should not be runtime... We know when we compile if we are
Lars in OSX or not.
Not in this part of code, which is system-independent.
The problem is that this information is not available either at OS or
GUI level. LyX/Qt running under mac os x can be either a Qt/X11 app or
a Qt/Mac one. OK, it is actually possible at GUI level to know that we
are using Qt/Mac.
However, this bundle thing is a packaging issue, and this code would
work identically if we were using a native Gtk port to aqua (does that
exist?). So we would need yet another abstraction for packaging (that
could be useful under windows too). The inOSXbundle code does that,
but does not separate the code in its own framework yet. I think it is
good enough until we try to be serious about this packaging issue.
Lars os::setupEnvironment();
Maybe is it true for PATH setting on OS X, except that you don't do
that to an X11 program. This code is only useful because installing
fink apps does not update the PATH seen by native apps.
Lars | + | + // | + // Determine locale directory | + // | + if
Lars (!GetEnv(LYX_LOCALEDIR).empty()) { | + localedir_ =
Lars GetEnv(LYX_LOCALEDIR); | + lyxerr[Debug::INIT]
Lars LYX_LOCALEDIR= localedir_ endl; | + } else if
Lars (inOSXBundle) { | + string const maybe_localedir = | +
Lars NormalizePath(AddPath(system_lyxdir_, ../locale)); | +
Lars FileInfo fi(maybe_localedir); | + if (fi.isOK() fi.isDir()) {
Lars | + lyxerr[Debug::INIT] | + LyX/Mac: setting locale
Lars directory to | + maybe_localedir endl; | + localedir_ =
Lars maybe_localedir;
Lars | + }
Lars } else { localedir_ = os::guessLocaleDir();
Lars }
Lars Btw is the maybe really a maybe? (the maybe will be used always)
Not if the directory does not exist.
Lars shouldn't this be fixed by LOCALEDIR in the first place, in the
Lars configure system?
No, because you want the app bundle to be relocatable, it will not
always live in /Applications. Mac users are used to be able to move
around the application icon (which is actually a directory containing
the whole app) and have it still working.
Lars use_lyxdir_ = os::preferencesDir();
Except that it should rather be a packaging::preferenceDir().
JMarc
Re: boost/cstdint.hpp:121: error
On Wed, Jun 02, 2004 at 04:12:14PM +0200, Lars Gullik Bj?nnes wrote: of gcc or lyx? lyx nothing in lyx/boost changed... automake/autoconf differences? I haven't changed versions of that. Your is some syntax problem, the one on FreeBSD is redefinition of a type. Either way, I can't do any LyX stuff. john
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
On Jun 2, 2004, at 10:45 AM, Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: I've tried the patch on LyX/Mac. While it doesn't seem to affect the focus issue (which, as Jean-Marc noted, is not a problem with qt-3.3.x), it does change dialogs to be always on top -- to be modal -- which is not desirable on the Mac, at least. Angus I'm not disputing your observations, but I do find them Angus surprising. The Qt docs for Qt 3.2 state: To modulate a bit Bennett's claim (as far as I understand his previous descriptions to me): the patch adds a stay-on-top behaviour to dialogs (I just checked that it happens on linux too), not modality (which would be to block the interface of the window below). It may be that the two are the same with Aqua, for focus policy reasons. That's right -- I guess I've misunderstood what's meant by modal. (You'll have to forgive my ignorance here -- one of the reasons I've mostly had private e-mail discussions with Jean-Marc.) The dialogs stay on top, but the window below is still accessible. It's only the stay-on-top behavior that's undesirable. (Angus' change to QDialogView, of course, produces no error messages when dialogs are called up.) Bennett
Re: future of win32 port?
Angus Leeming wrote: However, fltk version 2 no longer aims to provide this compatibility. Hmm, the fltk2 docs still state this to be true, and fluid also seems to work with fltk2. Moreover I found this message (and nothing contrary): http://www.fltk.org/newsgroups.php?s1+gfltk.general+Gfltk+v6 However, we're getting off topic ;-) Jürgen.
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: I've tried the patch on LyX/Mac. While it doesn't seem to affect the focus issue (which, as Jean-Marc noted, is not a problem with qt-3.3.x), it does change dialogs to be always on top -- to be modal -- which is not desirable on the Mac, at least. Angus I'm not disputing your observations, but I do find them Angus surprising. The Qt docs for Qt 3.2 state: To modulate a bit Bennett's claim (as far as I understand his previous descriptions to me): the patch adds a stay-on-top behaviour to dialogs (I just checked that it happens on linux too), not modality (which would be to block the interface of the window below). It may be that the two are the same with Aqua, for focus policy reasons. I'm not very good at bitwise fields, but a quick google turns up this if you want to ensure that your dialog is always on top. (QDialog dervies publicly from QWidget.) QWidget::setWFlags(Qt::WType_Dialog | Qt::WStyle_Customize | Qt::WStyle_StaysOnTop); So, is the negation of that: QWidget::setWFlags(Qt::WType_Dialog | Qt::WStyle_Customize Qt::WStyle_StaysOnTop); -- Angus
Re: future of win32 port?
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Perhaps there's some vague hope, although the development of Juergen this seems to be very slow: Juergen http://kde-cygwin.sourceforge.net/qt3-win32/ Did anyone try that? How far is it from usefulness? This is not very clear from the status pages or the mailing lists. JMarc
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus I'm not very good at bitwise fields, but a quick google turns Angus up this if you want to ensure that your dialog is always on Angus top. (QDialog dervies publicly from QWidget.) Angus QWidget::setWFlags(Qt::WType_Dialog | Qt::WStyle_Customize | Angus Qt::WStyle_StaysOnTop); Angus So, is the negation of that: Angus QWidget::setWFlags(Qt::WType_Dialog | Qt::WStyle_Customize Angus Qt::WStyle_StaysOnTop); Or maybe QWidget::setWFlags(Qt::WType_Dialog | Qt::WStyle_Customize ~Qt::WStyle_StaysOnTop); JMarc
Re: boost/cstdint.hpp:121: error
John Levon [EMAIL PROTECTED] writes: | On Wed, Jun 02, 2004 at 04:12:14PM +0200, Lars Gullik Bj?nnes wrote: of gcc or lyx? | lyx nothing in lyx/boost changed... automake/autoconf differences? | I haven't changed versions of that. Your is some syntax problem, the one on FreeBSD is redefinition of a type. | Either way, I can't do any LyX stuff. This is not helping! How can I help when you clam up on the info I need! -- Lgb
Re: future of win32 port?
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Jean-Marc Lasgouttes wrote: Did anyone try that? How far is it from usefulness? This is not very clear from the status pages or the mailing lists. Juergen Indeed. I wouldn't count on it yet. The clearest statement I Juergen found is this (from Feb 2004): Juergen http://lists.kde.org/?l=kde-cygwinm=107644957930216w=2 Nevertheless, I read more recently a message where Ralf discussed releasing a beta version. As far as I know, everything is still cygwin-based now. JMarc
Re: boost/cstdint.hpp:121: error
On Wed, Jun 02, 2004 at 05:19:50PM +0200, Lars Gullik Bj?nnes wrote: How can I help when you clam up on the info I need! What info do you want? john
Re: [OT] 'virulent' GPL
On Wed, Jun 02, 2004 at 08:56:23AM +0100, Iwo Mergler spake thusly: Hi all, you won't believe it, but some people are paranoid enough to think that using LyX to write a document somehow 'infects' the document with the GPL. Of course this is true... and viruses infect your machine through the power grid. So advise these folks to disconnect their machines from the grid and *keep them disconnected*, and I expect we'll see a lot less viruses ;-) Amazing what crazy ideas money can buy. - Martin pgp7n0LlQ3dM3.pgp Description: PGP signature
Re: boost/cstdint.hpp:121: error
John Levon [EMAIL PROTECTED] writes: | On Wed, Jun 02, 2004 at 05:19:50PM +0200, Lars Gullik Bj?nnes wrote: How can I help when you clam up on the info I need! | What info do you want? Tell me everything. But something _must_ have change I can't belive that it is lyx (sure it could be ...) -- Lgb
Re: boost/cstdint.hpp:121: error
On Wed, Jun 02, 2004 at 06:35:15PM +0200, Lars Gullik Bj?nnes wrote: But something _must_ have change I can't belive that it is lyx (sure it could be ...) Nothing's changed, honest. No RPMs have been updated. GCC 3.5 is the one that previously compiled lyx successfully. LyX is CVS up to date. I'll go investigate... john
make maintainer-clean dies in doc
Lars? -- Angus
Re: boost/cstdint.hpp:121: error
John Levon [EMAIL PROTECTED] writes: | On Wed, Jun 02, 2004 at 06:35:15PM +0200, Lars Gullik Bj?nnes wrote: But something _must_ have change I can't belive that it is lyx (sure it could be ...) | Nothing's changed, honest. No RPMs have been updated. GCC 3.5 is the one | that previously compiled lyx successfully. LyX is CVS up to date. | I'll go investigate... How updated are your 3.5? -- Lgb
Re: boost/cstdint.hpp:121: error
On Wed, Jun 02, 2004 at 06:48:07PM +0200, Lars Gullik Bj?nnes wrote:
How updated are your 3.5?
Very. The problem is that the gettext.m4 changes are doing:
typedef int ptrdiff_t
into config.h. However, the check is going wrong because of course
ptrdiff_t is defined fine on my system, so you e nd up with:
typedef int long
Here's the log (note I'm using CC=... CXX=... ./configure)
configure:28957: checking for ptrdiff_t
configure:28982: /usr/local/gcc-cvs/bin/gcc -c -g -O2
-I/usr/X11R6/include conftest.c 5
configure: In function `main':
configure:29059: error: 'ptrdiff_t' undeclared (first use in this
function)
configure:29059: error: (Each undeclared identifier is reported only
once
configure:29059: error: for each function it appears in.)
configure:29059: error: parse error before ')' token
configure:28985: $? = 1
configure: failed program was:
| #line 28962 configure
| /* confdefs.h. */
|
| #define PACKAGE_NAME lyx
| #define PACKAGE_TARNAME lyx
| #define PACKAGE_VERSION 1.4.0cvs
| #define PACKAGE_STRING lyx 1.4.0cvs
| #define PACKAGE_BUGREPORT [EMAIL PROTECTED]
| #define DEVEL_VERSION 1
| #define PACKAGE lyx
| #define VERSION 1.4.0cvs
| #define HAVE_KPSEWHICH 1
| #ifdef __cplusplus
| #include stdlib.h
| #endif
| #define WITH_WARNINGS 1
| #define HAVE_STD_COUNT 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_OSTREAM 1
| #define HAVE_ISTREAM 1
| #define HAVE_SSTREAM 1
| #define HAVE_LOCALE 1
| #define HAVE_LIMITS 1
| #define HAVE_IOS 1
| #define MODERN_STL_STREAMS 1
| #define ENABLE_ASSERTIONS 1
| #define HAVE_LIBM 1
| #define HAVE_LIBC 1
| #define AIKSAURUS_H_LOCATION
| #define HAVE_DLFCN_H 1
| #define HAVE_FLIMAGE_H 1
| #define USE_JPEG_IMAGE_LOADER 1
| #define HAVE_LONG_LONG 1
| #define HAVE_LONG_DOUBLE 1
| #define HAVE_WCHAR_T 1
| #define HAVE_WINT_T 1
| #define HAVE_INTTYPES_H_WITH_UINTMAX 1
| #define HAVE_STDINT_H_WITH_UINTMAX 1
| #define HAVE_INTMAX_T 1
| #define HAVE_POSIX_PRINTF 1
| #define HAVE_ALLOCA_H 1
| #define HAVE_ALLOCA 1
| #define HAVE_STDLIB_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_GETPAGESIZE 1
| #define HAVE_MMAP 1
| #define INTDIV0_RAISES_SIGFPE 1
| #define HAVE_UNSIGNED_LONG_LONG 1
| #define HAVE_UINTMAX_T 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_STDINT_H 1
| /* end confdefs.h. */
| #include stdio.h
| #if HAVE_SYS_TYPES_H
| # include sys/types.h
#endif
| #if HAVE_SYS_STAT_H
| # include sys/stat.h
| #endif
| #if STDC_HEADERS
| # include stdlib.h
| # include stddef.h
| #else
| # if HAVE_STDLIB_H
| # include stdlib.h
| # endif
| #endif
| #if HAVE_STRING_H
| # if !STDC_HEADERS HAVE_MEMORY_H
| # include memory.h
| # endif
| # include string.h
| #endif
| #if HAVE_STRINGS_H
| # include strings.h
| #endif
| #if HAVE_INTTYPES_H
| # include inttypes.h
| #else
| # if HAVE_STDINT_H
| # include stdint.h
| # endif
| #endif
| #if HAVE_UNISTD_H
| # include unistd.h
| #endif
| int
| main ()
| {
| if ((ptrdiff_t *) 0)
| return 0;
| if (sizeof (ptrdiff_t))
| return 0;
| ;
| return 0;
| }
configure:29002: result: no
john
Re: boost/cstdint.hpp:121: error
John Levon [EMAIL PROTECTED] writes: | On Wed, Jun 02, 2004 at 06:48:07PM +0200, Lars Gullik Bj?nnes wrote: How updated are your 3.5? | Very. The problem is that the gettext.m4 changes are doing: | typedef int ptrdiff_t | into config.h. However, the check is going wrong because of course | ptrdiff_t is defined fine on my system, so you e nd up with: | typedef int long Ok, then I wonder how is your system different from mine? | Here's the log (note I'm using CC=... CXX=... ./configure) So you are not changing the path to get gcc 3.5? I do this: #!/bin/bash export PATH=/opt/gcc-head/bin:$PATH export LD_LIBRARY_PATH=/opt/gcc-head/lib exec bash -i Does that make a difference? (change to fit of course) Do you have any clues why configure thinks your ptrdiff_t is undefined? My log: configure:29030: checking for ptrdiff_t configure:29055: gcc -c -g -O2 -I/usr/X11R6/include conftest.c 5 configure:29058: $? = 0 configure:29061: test -s conftest.o configure:29064: $? = 0 configure:29075: result: yes -- Lgb
Re: boost/cstdint.hpp:121: error
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | I do this: | #!/bin/bash | export PATH=/opt/gcc-head/bin:$PATH | export LD_LIBRARY_PATH=/opt/gcc-head/lib | exec bash -i | Does that make a difference? (change to fit of course) | Do you have any clues why configure thinks your ptrdiff_t is | undefined? | My log: | configure:29030: checking for ptrdiff_t | configure:29055: gcc -c -g -O2 -I/usr/X11R6/include conftest.c 5 | configure:29058: $? = 0 | configure:29061: test -s conftest.o | configure:29064: $? = 0 | configure:29075: result: yes The strangest thing. When I take your conftest.c and run gcc on it: configure: In function `main': configure:29059: error: `ptrdiff_t' undeclared (first use in this function) configure:29059: error: (Each undeclared identifier is reported only once configure:29059: error: for each function it appears in.) configure:29059: error: syntax error before ')' token gcc --version gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1) I can only find ptrdiff_t in linux/types.h and in /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include/stddef.h (which leads me to suspect your way of calling the compiler...) It seems that STDC_HEADERS is undefined with your test. Can you check that? -- Lgb
Re: [patch] bug 1530 --- Mac OS X dialogs often don't have focus
Angus Leeming wrote:
Angus Yes. I followed the prescription outlined in the bug report.
Angus Without the patch, keyboard input went to the lyx screen.
With Angus the patch, it went to the index dialog.
And does it give you a 'stay on top' behaviour?
Yes, so I've reversed the patch.
Am I right in saying that this problem (bug 1530) will just go away
with Qt 3.3.x?
Given that not everybody has access to 3.3.x, does the patch below not
solve the problem? It seems to work here with Qt 3.1.2...
Index: src/frontends/qt2//QDialogView.C
===
RCS file:
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QDialogView.C,v
retrieving revision 1.11
diff -u -p -r1.11 QDialogView.C
--- src/frontends/qt2//QDialogView.C20 May 2004 09:36:27 -
1.11
+++ src/frontends/qt2//QDialogView.C2 Jun 2004 20:24:16 -
@@ -59,6 +59,7 @@ void QDialogView::show()
} else {
form()-show();
}
+ form()-setFocus();
}
--
Angus
Re: boost/cstdint.hpp:121: error
On Wed, Jun 02, 2004 at 08:46:51PM +0200, Lars Gullik Bj?nnes wrote: I can only find ptrdiff_t in linux/types.h and in /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include/stddef.h (which leads me to suspect your way of calling the compiler...) It seems that STDC_HEADERS is undefined with your test. Can you check that? Ouch, OK, this is completely pilot error. I had a mis-typed LD_LIBRARY_PATH. Sorry for the fuss. regard john
Re: boost/cstdint.hpp:121: error
John Levon [EMAIL PROTECTED] writes: | On Wed, Jun 02, 2004 at 08:46:51PM +0200, Lars Gullik Bj?nnes wrote: I can only find ptrdiff_t in linux/types.h and in /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include/stddef.h (which leads me to suspect your way of calling the compiler...) It seems that STDC_HEADERS is undefined with your test. Can you check that? | Ouch, OK, this is completely pilot error. I had a mis-typed | LD_LIBRARY_PATH. Sorry for the fuss. Ha! I win! -- Lgb
Re: boost/cstdint.hpp:121: error
On Thu, Jun 03, 2004 at 12:31:01AM +0200, Lars Gullik Bj?nnes wrote: Ha! I win! I gracefully concede (this one). But only because I appear to have burnt my nose. john
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes wrote:
Rob Lahaye [EMAIL PROTECTED] writes:
Ok, it must be FreeBSD that is the problem
Is uintmax_t a macro? Or uint32_t?
Has inttypes.h on FreeBSD changed recently?
(upgraded libc perhaps?)
What is uintmax_t/uint32_t typdeffed/defined as in inttypes.h
| This is what I get:
| $ grep -n uintmax_t /usr/include/inttypes.h
| $ grep -n uint32_t /usr/include/inttypes.h
| /usr/include/inttypes.h:18:typedef __uint32_t uint32_t;
| Is that causing the trouble?
Not directly. This compiles:
typedef long tull;
typedef tull tall;
int main()
{}
Where does __uint32_t come from?
All this is going a bit beyond my level of understanding the compilation process.
I have these results:
1) Everything compiles like a charm, when I comment out in
boost/boost/cstdint.hpp this line
// typedef uint64_t uintmax_t;
2) When I keep the offending typedef line in boost/boost/cstdint.hpp
and comment out in /usr/include/inttypes.h this line:
//typedef __uint64_t uint64_t;
I get another (obvious?) error during the compilation:
[...snip...]
depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
/usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I.
-I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include
-DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c -o
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
/usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost
-I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -g -O
-fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF
.deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o
In file included from ../../../../boost/boost/regex/config.hpp:54,
from cpp_regex_traits.cpp:22:
../../../../boost/boost/cstdint.hpp:116: error: `uint64_t' not declared
../../../../boost/boost/cstdint.hpp:117: error: syntax error before `;' token
../../../../boost/boost/cstdint.hpp:118: error: syntax error before `;' token
../../../../boost/boost/cstdint.hpp:121: error: syntax error before `unsigned'
gmake[4]: *** [cpp_regex_traits.lo] Error 1
[.and many more error lines, related to above error]
What else can I do, to clarify this problem?
Regards,
Rob.
Re: boost/cstdint.hpp:121: error
Rob Lahaye [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
Rob Lahaye [EMAIL PROTECTED] writes:
Ok, it must be FreeBSD that is the problem
Is uintmax_t a macro? Or uint32_t?
Has inttypes.h on FreeBSD changed recently?
(upgraded libc perhaps?)
What is uintmax_t/uint32_t typdeffed/defined as in inttypes.h
| This is what I get:
| $ grep -n uintmax_t /usr/include/inttypes.h
| $ grep -n uint32_t /usr/include/inttypes.h
| /usr/include/inttypes.h:18:typedef __uint32_t uint32_t;
| Is that causing the trouble?
Not directly. This compiles:
typedef long tull;
typedef tull tall;
int main() {}
Where does __uint32_t come from?
| All this is going a bit beyond my level of understanding the
| compilation process.
You don't have to understand the compilation process, but to fix this
(and the correct fix is not just to comment out the offending line)
you have to help me find out what the correct fix is. So we dig
backwards, first trying to figure out why the code fails in the first
place. And to find out where uint32_t comes from we need to find out
where __uint32_t comes from.
| I have these results:
| 1) Everything compiles like a charm, when I comment out in
| boost/boost/cstdint.hpp this line
| // typedef uint64_t uintmax_t;
| 2) When I keep the offending typedef line in boost/boost/cstdint.hpp
| and comment out in /usr/include/inttypes.h this line:
| //typedef __uint64_t uint64_t;
| I get another (obvious?) error during the compilation:
| [...snip...]
| depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
| /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33
-DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include
-I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall
-c -o cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo
'./'`cpp_regex_traits.cpp
| /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost
-I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -g -O
-fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF
.deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o
| In file included from ../../../../boost/boost/regex/config.hpp:54,
| from cpp_regex_traits.cpp:22:
| ../../../../boost/boost/cstdint.hpp:116: error: `uint64_t' not
| declared
So commenting out the line in inttypes.h is not the solution.
| What else can I do, to clarify this problem?
Is __uint64_t a typedef? Or a macro?
--
Lgb
Re: reLyX - tex2lyx - maturity
Lars Gullik Bjønnes wrote: > How mature is tex2lyx? Is it anywhere close to replace reLyX? I have successfully used tex2lyx to convert a big document (~230 pages, lots of formulas and figures, edited by several authors with very different latex knowledge) last month. I found and fixed some bugs during this process (also the environment nesting bug that was the only remaining one that showed up when converting the userguide), and will feed them back when I find some time and the rest of the graphics conversion bugs are done. tex2lyx hase some problems with tables, but I don't know if reLyX is better there. The rest (at least my fixed version) is in my experience already better than reLyX, so IMHO tex2lyx could become the default converter. Georg
Re: reLyX - tex2lyx - maturity
Georg Baum <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: > >> How mature is tex2lyx? Is it anywhere close to replace reLyX? > | I have successfully used tex2lyx to convert a big document (~230 pages, lots | of formulas and figures, edited by several authors with very different | latex knowledge) last month. I found and fixed some bugs during this | process (also the environment nesting bug that was the only remaining one | that showed up when converting the userguide), and will feed them back when | I find some time and the rest of the graphics conversion bugs are done. Very good. (please find time :-) ) | tex2lyx hase some problems with tables, but I don't know if reLyX is better | there. The rest (at least my fixed version) is in my experience already | better than reLyX, so IMHO tex2lyx could become the default converter. Ok. The reason for my question is that I want to get rid of reLyX completely, but only if we have a working alternative. (tex2lyx) -- Lgb
[OT] 'virulent' GPL
Hi all, you won't believe it, but some people are paranoid enough to think that using LyX to write a document somehow 'infects' the document with the GPL. That is, the document and its contents automatically become GPL too. I know this is stupid. Could anyone point me to a suitable legal document which states this isn't the case under GPL? It would help me resolve a dispute I still can't belive I'm having. Kind regards, Iwo
Re: [OT] 'virulent' GPL
Iwo Mergler wrote: > Could anyone point me to a suitable legal document > which states this isn't the case under GPL? It would > help me resolve a dispute I still can't belive I'm having. The GPL itself? §0: "[...] Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does." Also see the GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html#GPLOutput Regards, Jürgen.
future of win32 port?
Dear LyX developers, thank you (again) for your LyX development. After some pause I'm again with LyX (hoping) to stay :-) Since it is such a good program I'd liek to share it with some friends who are still on Win32 platform. It's not easy to persuade Word user in a LaTeX/TeX world, but LyX can bridge the gap nicely. However, I'm concerned abut the future of Win32 port since it is based on free version of qt which is not offered for the latest qt incarnations. Does it mean that win32 port is cursed to stay in the old mud? Has anyone considered to do a wxWidgets port? Is it a big task considering the present status of LyX's GUI-independence? Sincerely, Gour -- Gour| [EMAIL PROTECTED] Registered Linux User | #278493 GPG Public Key | 8C44EDCD pgpHd0VcBqeDq.pgp Description: PGP signature
One reason for failure of external scripts on Win32
On Tuesday 01 June 2004 6:45 pm, Angus Leeming wrote: > On Tuesday 01 June 2004 6:27 pm, Timm Danker wrote: > > Angus, > > I just realised that I get the same error message regardless > > whats in the lyxpreview2bitmap.sh. its sufficient that it is just > > there in the ./lyx/scripts directory. its not evaluated it seems. > > > > this is the error message > > > > C:/Dokumente: C:/Dokumente: No such file or directory > > LyX: Child (pid: 220) stopped on signal 0. Waiting for child to > > finish. LyX: Error waiting for child: No child processes > > > > note that with my way of placing the files, it works fine for me. > > But since you seem to dislike a solution that not uses the ./lyx > > directory, it would be nice for the other wiki users if we find > > out whats going on here. Tell me if i can be helpful with testing > > or something. > > > > Timm > > Yes, that makes sense. The script is invoked by LyX as: > > sh C:/Dokumente und Einstellungen/.lyx/scripts/lyxpreview2bitmap.sh > > We should wrap the name in quotes. > > H. Can you invoke an executable wrapped in quotes. What's the > result of running this from the command line? > > PROMPT> echo angus | "sed" "s/a/b/" > > Here, on a unix box, I get 'bngus', indicating all worked as > expected. Timm confirms that this works on Win32 also, so it seems that we have a way out: when invoking an external script, we should wrap the argument in quotes (using QuoteName) if we have replaced one of the placeholders $$a, $$i, $$o, $$p, $$s, $$FName, $$FPath, $$AbsPath, $$RelPathMaster, $$RelPathParent, $$AbsOrRelPathMaster, $$AbsOrRelPathParent, $$Tempname, $$Sysdir, $$LyX, $$User Unfortunately, doing so is going to be a real PITA. Angus
Re: future of win32 port?
Angus Leeming ([EMAIL PROTECTED]) wrote: > No. But a gtk port has made progress. (gtk is licensed under the LGPL > and has been ported to Win32.) The main LyX window is functional and > a couple of the dialogs have been ported. The rest of the dialogs are > from the XForms frontend. Thank you for this info. Is there any reason why wxWidgets toolkit is (somehow) avoided? It's not that I'm pushing it, but, imho, it looks like a mature multi-platform toolkit with a fair licence. Sincerely, Gour -- Gour| [EMAIL PROTECTED] Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Re: future of win32 port?
Gour <[EMAIL PROTECTED]> writes: | Angus Leeming ([EMAIL PROTECTED]) wrote: > >> No. But a gtk port has made progress. (gtk is licensed under the LGPL >> and has been ported to Win32.) The main LyX window is functional and >> a couple of the dialogs have been ported. The rest of the dialogs are >> from the XForms frontend. > | Thank you for this info. > | Is there any reason why wxWidgets toolkit is (somehow) avoided? Only that nobody has done, or been interested enough to do the actual work. -- Lgb
Re: future of win32 port?
On Wed, 2 Jun 2004 11:01:24 +0200 Gour <[EMAIL PROTECTED]> wrote: > Is there any reason why wxWidgets toolkit is (somehow) avoided? Well, I think someone would have to do it :) > It's not that I'm pushing it, but, imho, it looks like a mature > multi-platform toolkit with a fair licence. The more "natural" Toolkit for LyX would be FLTK I think, because it seems to be quite close to xforms. But that would have to be done as well... Karsten
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes wrote: John Levon <[EMAIL PROTECTED]> writes: | On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote: My make of up-to-date LyX-CVS ends with: | Me too (well, something similar) gcc 3.5.0cvs I don't get either. I need this, to successfully compile CVS: Index: boost/boost/cstdint.hpp === RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v retrieving revision 1.5 diff -u -r1.5 cstdint.hpp --- boost/boost/cstdint.hpp 2004/02/05 09:14:14 1.5 +++ boost/boost/cstdint.hpp 2004/06/02 08:24:38 @@ -118,7 +118,7 @@ typedef uint64_t uint_fast64_t; typedef int64_t intmax_t; - typedef uint64_t uintmax_t; +// typedef uint64_t uintmax_t; # else Any ideas why this obstructs the compilation? Compiler: gcc 3.3.4 20040505 (prerelease) Regards, Rob.
Re: boost/cstdint.hpp:121: error
Rob Lahaye <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> John Levon <[EMAIL PROTECTED]> writes: >> | On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote: >> My make of up-to-date LyX-CVS ends with: >>> >> | Me too (well, something similar) gcc 3.5.0cvs >> I don't get either. >> > | I need this, to successfully compile CVS: > > | Index: boost/boost/cstdint.hpp | === | RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v | retrieving revision 1.5 | diff -u -r1.5 cstdint.hpp | --- boost/boost/cstdint.hpp 2004/02/05 09:14:14 1.5 | +++ boost/boost/cstdint.hpp 2004/06/02 08:24:38 | @@ -118,7 +118,7 @@ | typedef uint64_t uint_fast64_t; > | typedef int64_t intmax_t; | - typedef uint64_t uintmax_t; | +// typedef uint64_t uintmax_t; > | # else > > | Any ideas why this obstructs the compilation? | Compiler: gcc 3.3.4 20040505 (prerelease) I doubt that this has anything to do with the compiler. I do not see the problem with gcc 3.3.2 , 3.3.3 nor 3.5 prerelease. What is the full error message you get? And what kind of system are you compiling on? -- Lgb
Re: reLyX - tex2lyx - maturity
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Lars Gullik Bjønnes wrote: >> How mature is tex2lyx? Is it anywhere close to replace reLyX? Georg> I found and fixed some bugs during this process (also the Georg> environment nesting bug that was the only remaining one that Georg> showed up when converting the userguide), and will feed them Georg> back when I find some time and the rest of the graphics Georg> conversion bugs are done. Thanks for doing that. I was dragging my feet on this one, and it seems that it paid off :) Georg> tex2lyx hase some problems with tables, but I don't know if Georg> reLyX is better there. The rest (at least my fixed version) is Georg> in my experience already better than reLyX, so IMHO tex2lyx Georg> could become the default converter. One thing that needs to be done maybe is to implement roughly the same set of command line options as reLyX. Also, there is code in reLyX to skip preamble parts generated by LyX (useful for round trip). These would be useful and easy to add. JMarc
Re: [doc] What is TOC_top/ru_TOC_top.lyx
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> What is this? Lars> TOC_top/ru_TOC_top.lyx TOC_top files are documents with the proper language setting and title that are use to generate the corresponding TOC file. Does this answer your question? JMarc
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes wrote: Rob Lahaye <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: John Levon <[EMAIL PROTECTED]> writes: | On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote: My make of up-to-date LyX-CVS ends with: | Me too (well, something similar) gcc 3.5.0cvs I don't get either. | I need this, to successfully compile CVS: | Index: boost/boost/cstdint.hpp | === | RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v | retrieving revision 1.5 | diff -u -r1.5 cstdint.hpp | --- boost/boost/cstdint.hpp 2004/02/05 09:14:14 1.5 | +++ boost/boost/cstdint.hpp 2004/06/02 08:24:38 | @@ -118,7 +118,7 @@ | typedef uint64_t uint_fast64_t; | typedef int64_t intmax_t; | - typedef uint64_t uintmax_t; | +// typedef uint64_t uintmax_t; | # else | Any ideas why this obstructs the compilation? | Compiler: gcc 3.3.4 20040505 (prerelease) I doubt that this has anything to do with the compiler. I do not see the problem with gcc 3.3.2 , 3.3.3 nor 3.5 prerelease. What is the full error message you get? And what kind of system are you compiling on? autogen.sh: Using autoconf (GNU Autoconf) 2.53 gmake: [...snip...] gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src' source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \ depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \ depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \ /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG="" -g -O -fno-exceptions -W -Wall -c -o cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include "-DBOOST_USER_CONFIG=" -g -O -fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF .deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o In file included from ../../../../boost/boost/regex/config.hpp:54, from cpp_regex_traits.cpp:22: ../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in type `long' gmake[4]: *** [cpp_regex_traits.lo] Error 1 - FreeBSD 4.10-STABLE i386 GCC 3.3.4 20040505 (prerelease) [FreeBSD] Rob.
