LyX on NT/2K w/Cygwin-1.1.2 (was Re: LyX 1.1.5 for Win32)
Claus, thanks a lot for your answer, I 'll cc this to the devel list since it might interest the guys there. As it looks like, we made the exact same experiences. My version of cygwin I used to have cygwin-b20 and was naive enough to delete my old installation and get the all new version... Anyway, I have cygwin-1.1.2 net release with gcc-2.95.2. I did _not_ install the X11R6.4 libraries and header files from the cygwin site, but I had these with cygwin-b20 and, yes, the header files X11.h and Xutil.h cause gcc-2.95.2 to freak out... The X11R6.4 release is outdated and should no longer be used. I did report this to the cygwin list but I was told more or less to shut up Setting -fpermissive allowed me to compile LyX w/cygwin-b20. My conclusion is that the X11R6.4 package from the cygwin site is way outdated. The headers seem to be older than what you will find on Linux for example. I therefore got the Xfree86 stuff from the cygwin site and I do not have problems with these warnings anymore. Xforms Yes, forms library is not correctly recognized even when you specify --with-extra-inc --with-extra-lib. This might be because 0.881 is fairly old, yet the newest one you can find for cygwin. If I need to say anything else about the dreaded xforms library I'll just get mad so I wont. manually adding xforms Yes, same here ignoring the warning and manually modifying config.status to include the libraries will compile everything almost cleanly (except for warnings for the rb_tree inline stuff). But linking fails with the unresolved symbol _ctype_ . A change in the glibc could be the reason, I am not sure where the undefined symbol comes from maybe it is libforms.a in that case we are s.o.l. and a new forms library is mandatory to get things to run with cygwin-1.1. I know that some of the developers are on the Xforms mailing list. Xforms is moving extremely slow these days and it is becoming more obsolete know that even Motif has at least halfway seen the light. Anyway maybe someone could get a new version of Xforms to be compiled against cygwin-1.1.2 but I kinda doubt it. I will probably move back to cygwin-b20 for now. Good luck - please keep me posted. I would very much like a package the one could "just install". There is even rpm for windows these days, rpm beats all the windows installers hands down a million times. XFree86 Looking good, I got it to run on my NT box, full screen mode only, but hey - this is a huge step forward. Put on KDE and run it as the default shell instead of explorer and you'd have a decent environment on NT :-) Well, just kidding, but as a free solution this is not bad at all. Thanks Roland Claus Hentschel wrote: Roland, here is my answer to your questions mailed this weekend: could you post a few instructions on how you did the port, i.e. which version of Cygwin and xforms? I am having some trouble with the latest cvs code, i.e. I get errors when compiling from the forms.h header files Really strange since it used to work. I am using cygwin-1.1.2 the net release and bxforms-0881 from the xforms website. Also which version of X11 do you have? I always get tons of warnings and I have to set the compiler switch -fpermissive in config.status. I am using XFree86-4.0 from the Cygwin website. The released version has been compiled with cygnus b20.1 and xforms-0881 for win32 from the xforms website. I am using an x11r64 release which fetched from a site which I didn't remember because of some win9x crashes. Last week I installed cygwin 1.1.2 and the official X11R6.4 package for b20.1! And -- same as you have written -- I got tons of error messages. At the moment I have fixed Xlib.h and Xutil.h which allows compiling without the -fpermissive flag set. Problems I have detected for now: 1. libforms.a isn't recognized although installed correctly in /usr/lib ? 2. Manually setting -lforms in the src-Makefile leads in some unresolved externals. All telling me that '_ctype_' isn't recognized for many functions in libforms.a So I cannot link Lyx.exe with the new release! You told, that with your installation you can build lyx.exe!? So what is different at your site? Maybe you can explain me a little bit more your environment. I think: It's time to move to cygwin 1.1 because the new release of cygwin seams to be much more stable than b20.1!! PS: For all you guys that cant afford a real X-server :-) The Cygwin guys now have a "stable" port of XFree86 for Windows - It is quite amazing after all these years. I have not tried LyX with it but as soon as I get it to compile I'll test it. That is very interesting!!! So it maybe possible to present a real out-of-the-box package with ALL you need to run LyX! Please send me details of your tests! Thats for now! Regards Claus -- Dr.-Ing. Roland Krause Engineering Software Research and Development Inc, Saint Louis, MO voice: (314) 983 0649-12
LyX on NT/2K w/Cygwin-1.1.2 (was Re: LyX 1.1.5 for Win32)
Claus, thanks a lot for your answer, I 'll cc this to the devel list since it might interest the guys there. As it looks like, we made the exact same experiences. >> My version of cygwin << I used to have cygwin-b20 and was naive enough to delete my old installation and get the all new version... Anyway, I have cygwin-1.1.2 net release with gcc-2.95.2. I did _not_ install the X11R6.4 libraries and header files from the cygwin site, but I had these with cygwin-b20 and, yes, the header files X11.h and Xutil.h cause gcc-2.95.2 to freak out... The X11R6.4 release is outdated and should no longer be used. I did report this to the cygwin list but I was told more or less to shut up Setting -fpermissive allowed me to compile LyX w/cygwin-b20. My conclusion is that the X11R6.4 package from the cygwin site is way outdated. The headers seem to be older than what you will find on Linux for example. I therefore got the Xfree86 stuff from the cygwin site and I do not have problems with these warnings anymore. << Xforms >> Yes, forms library is not correctly recognized even when you specify --with-extra-inc --with-extra-lib. This might be because 0.881 is fairly old, yet the newest one you can find for cygwin. If I need to say anything else about the dreaded xforms library I'll just get mad so I wont. << manually adding xforms >> Yes, same here ignoring the warning and manually modifying config.status to include the libraries will compile everything almost cleanly (except for warnings for the rb_tree inline stuff). But linking fails with the unresolved symbol _ctype_ . A change in the glibc could be the reason, I am not sure where the undefined symbol comes from maybe it is libforms.a in that case we are s.o.l. and a new forms library is mandatory to get things to run with cygwin-1.1. I know that some of the developers are on the Xforms mailing list. Xforms is moving extremely slow these days and it is becoming more obsolete know that even Motif has at least halfway seen the light. Anyway maybe someone could get a new version of Xforms to be compiled against cygwin-1.1.2 but I kinda doubt it. I will probably move back to cygwin-b20 for now. Good luck - please keep me posted. I would very much like a package the one could "just install". There is even rpm for windows these days, rpm beats all the windows installers hands down a million times. << XFree86>> Looking good, I got it to run on my NT box, full screen mode only, but hey - this is a huge step forward. Put on KDE and run it as the default shell instead of explorer and you'd have a decent environment on NT :-) Well, just kidding, but as a free solution this is not bad at all. Thanks Roland Claus Hentschel wrote: > Roland, > > here is my answer to your questions mailed this weekend: > > > could you post a few instructions on how you did the port, i.e. which > > version of Cygwin and xforms? I am having some trouble with the latest cvs > > code, i.e. I get errors when compiling from the forms.h header files > > Really strange since it used to work. I am using cygwin-1.1.2 the net > > release and bxforms-0881 from the xforms website. Also which version of > X11 > > do you have? I always get tons of warnings and I have to set the compiler > > switch -fpermissive in config.status. > > I am using XFree86-4.0 from the Cygwin website. > > The released version has been compiled with cygnus b20.1 and xforms-0881 for > win32 from the xforms website. I am using an x11r64 release which fetched > from a site which I didn't remember because of some win9x crashes. > > Last week I installed cygwin 1.1.2 and the official X11R6.4 package for > b20.1! And -- same as you have written -- I got tons of error messages. At > the moment I have fixed Xlib.h and Xutil.h which allows compiling without > the -fpermissive flag set. > > Problems I have detected for now: > 1. libforms.a isn't recognized although installed correctly in /usr/lib > ? > 2. Manually setting -lforms in the src-Makefile leads in some unresolved > externals. All telling me that '_ctype_' isn't recognized for many functions > in libforms.a > > So I cannot link Lyx.exe with the new release! > > You told, that with your installation you can build lyx.exe!? So what is > different at your site? Maybe you can explain me a little bit more your > environment. I think: It's time to move to cygwin 1.1 because the new > release of cygwin seams to be much more stable than b20.1!! > > > PS: For all you guys that cant afford a real X-server :-) The Cygwin guys > > now have a "stable" port of XFree86 for Windows - It is quite amazing > after > > all these years. I have not tried LyX with it but as soon as I get it to > > compile I'll test it. > > That is very
Re: Report from the beer-festivitiesch [burp]
He he :-) The last time they did this kind of "meeting" the development got stalled for about a year or so because the participants werent able to figure out what they had done to the development branch after they got sober again... He he I just wish I could be there to prevent the worst (i.e. drink all the beer before they can do too much damage). Have fun guys - dont worry to much about coding LyX is becoming better every day. Roland -- Dr.-Ing. Roland Krause Engineering Software Research and Development Inc, Saint Louis, MO voice: (314) 983 0649-12
Re: Report from the beer-festivitiesch [burp]
He he :-) The last time they did this kind of "meeting" the development got stalled for about a year or so because the participants werent able to figure out what they had done to the development branch after they got sober again... He he I just wish I could be there to prevent the worst (i.e. drink all the beer before they can do too much damage). Have fun guys - dont worry to much about coding LyX is becoming better every day. Roland -- Dr.-Ing. Roland Krause Engineering Software Research and Development Inc, Saint Louis, MO voice: (314) 983 0649-12
Re: V1.14fix2 on Win32
Claus Hentschel wrote:
I have analyzed the problem on Win32 compared to Linux on my system. The
problem is, that LyX - correctly! - inserted the \document_path. On
Win32/MS-DOS cygnus maps all drives like c:, d: etc. into the drive
character prefixed with '//', i.e. '//c' and '//d'.
All external viewer programs still are Win32/DOS programs and cannot find a
file with that starting sequence. So just 2 minutes ago I have placed a
patch into src/buffer.C near line 1625:
#ifdef WIN9X
LFile += "\\def\\input@path{{";
{
string dos_path = original_path;
if( dos_path.compare(0,2,"//") == 0 ) {
dos_path.erase(0,2);
dos_path.insert(1,":");
LFile += dos_path;
} else
LFile += original_path;
}
LFile += "/}}\n";
#else
LFile += "\\def\\input@path{{" + original_path
+ "/}}\n";
#endif
A question, wouldnt it be a lot better to use cygpath -w? This is how yap and
gsview32 are currently called on the Windows platform with no problems. Why not
using the same syntax in lyxrc for all calls to external programs? Then we can
avoid hacks like that. I admit I havent followed this from the beginning though.
---8
Roland
--
Dr.-Ing. Roland Krause
Engineering Software Research and Development Inc, Saint Louis, MO
voice: (314) 983 0649-12
Re: V1.14fix2 on Win32
Claus Hentschel wrote:
> I have analyzed the problem on Win32 compared to Linux on my system. The
> problem is, that LyX - correctly! - inserted the \document_path. On
> Win32/MS-DOS cygnus maps all drives like c:, d: etc. into the drive
> character prefixed with '//', i.e. '//c' and '//d'.
>
> All external viewer programs still are Win32/DOS programs and cannot find a
> file with that starting sequence. So just 2 minutes ago I have placed a
> patch into src/buffer.C near line 1625:
>
> #ifdef WIN9X
>LFile += "\\def\\input@path{{";
>{
> string dos_path = original_path;
>
> if( dos_path.compare(0,2,"//") == 0 ) {
> dos_path.erase(0,2);
> dos_path.insert(1,":");
> LFile += dos_path;
> } else
> LFile += original_path;
>}
>LFile += "/}}\n";
> #else
>LFile += "\\def\\input@path{{" + original_path
> + "/}}\n";
> #endif
>
A question, wouldnt it be a lot better to use cygpath -w? This is how yap and
gsview32 are currently called on the Windows platform with no problems. Why not
using the same syntax in lyxrc for all calls to external programs? Then we can
avoid hacks like that. I admit I havent followed this from the beginning though.
--->8
Roland
--
Dr.-Ing. Roland Krause
Engineering Software Research and Development Inc, Saint Louis, MO
voice: (314) 983 0649-12
Re: XTL and FormPrint now in rae branch
On Mon, 20 Mar 2000, Allan Rae wrote: On Fri, 17 Mar 2000, Allan Rae wrote: Read the comments in the various files. Have fun I'm off to catch a bus. Well I had a great weekend, reading my Guidebook to Europe, no thesis work though. Did anybody attempt to compile or read any of this stuff? When did you check it in - I could see anything new on Friday night? I'll try again today. Roland Allan. (ARRae)
Re: XTL and FormPrint now in "rae" branch
On Mon, 20 Mar 2000, Allan Rae wrote: > On Fri, 17 Mar 2000, Allan Rae wrote: > > Read the comments in the various files. Have fun I'm off to catch a bus. > > Well I had a great weekend, reading my Guidebook to Europe, no thesis > work though. Did anybody attempt to compile or read any of this stuff? When did you check it in - I could see anything new on Friday night? I'll try again today. Roland > > Allan. (ARRae)
Re: Behaviour of Fractions - Feature Request
LyX does not have anything to do with this behaviour. It depends solely on the Latex class that you are using. Latex uses a smaller font for fractions when in multiline equations (\eqnarray), you can theoretically put \displaystyle around your arguments to prevent this but it is ugly and makes the equations hard to read. Your question is probably better suited for the user list, since there are some real Latex experts that can hopefully help you. Roland On Wed, 01 Mar 2000, you wrote: Would it be possiable to include a second fraction type which does not use a smaller font for the numeriator and denominator. 1. The current behaviour is ideal for simple numeric or algebriac fraction like: y=1/2 or y=a/b 2. However this is not particularly suitable for longer equations, or those requiring multiple fractions in the form: y=(-b(+-)SqRoot(b^2-4ac))/2a or y=((a/b) + (c/d)) / (e/f)) This, apparently would require an additional type which did not affect the size of font used and therefore allow a more spacious appearance to the final printed formulae. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: Behaviour of Fractions - Feature Request
LyX does not have anything to do with this behaviour. It depends solely on the Latex class that you are using. Latex uses a smaller font for fractions when in multiline equations (\eqnarray), you can theoretically put \displaystyle around your arguments to prevent this but it is ugly and makes the equations hard to read. Your question is probably better suited for the user list, since there are some real Latex experts that can hopefully help you. Roland On Wed, 01 Mar 2000, you wrote: > Would it be possiable to include a second fraction > type which does not use a smaller font for the > numeriator and denominator. > > 1. The current behaviour is ideal for simple numeric > or algebriac fraction like: > > y=1/2 > or > > y=a/b > > 2. However this is not particularly suitable for > longer equations, or those requiring multiple > fractions in the form: > > y=(-b(+-)SqRoot(b^2-4ac))/2a > > or > > y=((a/b) + (c/d)) / (e/f)) > > This, apparently would require an additional type > which did not affect the size of font used and > therefore allow a more spacious appearance to the > final printed formulae. > > > __ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com
Re: LyX Development News
On a related note, there was some discussion about Office suites on /. the other day and of course LyX got mentioned, that is actually KLyX got mentioned and not LyX :-( From the little discussion that involved LyX the notion: "What's happening? Are you ever going to do anything? I reckon XForms sucks and you should use blah-tk instead" became again visible. And I admit having had that impression myself once in a while (before following the devel-list). Anyway the /. insident shows two things: - LyX is still a household name in the community but people look at KLyX first then drop LyX alltogether because KLyX doesnt have half the functionality of LyX. KLyX with official version number 0.10.7 for now over 2 years makes occasional visitors think the project is dead - XForms is a major obstacle in LyX popularity. I have two ideas: Could we ask Matthias Ettrich to take down the KLyX homepage and instead point to our page where in exchange for the favor a KLyX section is somewhat maintained. We actually have the KLyX section already. Should we set up a nonprofit organization and lobby for corporate sponsorship? A target would e.g. be O'Reilly. As a publisher they might have interest in the LyX program. This way, maybe a part time developer could be financed. Together we could sent Alan on a year long hacking tour :-) and then save for his liver transplant. Certain tasks could be "sourced out" to SourceXChange or CoSource. I think O'Reilly could have some major interest in sponsoring LyX in exchange we could make cls and layouts for the animal series, improve docbook support and XML. Roland On Wed, 23 Feb 2000, Allan Rae wrote: I also think it'd be worthwhile to keep this thread running ad infinitum with individuals posting whatever snippets from their respective subprojects they want included in LDN. That way I don't have to write everything myself and hopefully someone else might step forward to act as editor. Hot topics for next weeks LDN: + Kayvan and Jacek's RPMs + double-space? + GUI-independence (dialogs, libsigc++ + XTL) hopefully reduce the number of "What's happening? Are you ever going to do anything? I reckon XForms sucks and you should use blah-tk instead" + Insets? What's happening with the inset family (ERT, text etc.) Maybe I should just settle on several small news items and one feature area per fortnight. So I'd feature either GUI-indep or Insets depending on which one of them gets written in time (Jürgen or Lars could you scribble a couple of paragraphs or provide a copy of an old email you think would suit). We still need someone to gather together the threads of discussion about mini-projects like citations (natbib, harvard etc. support), pdflatex, layout file extensions and any number of other areas so we can have a mini-project page and maybe snare us some new talent. Allan. (ARRae)
Re: LyX Development News
On a related note, there was some discussion about Office suites on /. the other day and of course LyX got mentioned, that is actually KLyX got mentioned and not LyX :-( >From the little discussion that involved LyX the notion: "What's happening? Are you ever going to do anything? I reckon XForms sucks and you should use blah-tk instead" became again visible. And I admit having had that impression myself once in a while (before following the devel-list). Anyway the /. insident shows two things: - LyX is still a household name in the community but people look at KLyX first then drop LyX alltogether because KLyX doesnt have half the functionality of LyX. KLyX with official version number 0.10.7 for now over 2 years makes occasional visitors think the project is dead - XForms is a major obstacle in LyX popularity. I have two ideas: Could we ask Matthias Ettrich to take down the KLyX homepage and instead point to our page where in exchange for the favor a KLyX section is somewhat maintained. We actually have the KLyX section already. Should we set up a nonprofit organization and lobby for corporate sponsorship? A target would e.g. be O'Reilly. As a publisher they might have interest in the LyX program. This way, maybe a part time developer could be financed. Together we could sent Alan on a year long hacking tour :-) and then save for his liver transplant. Certain tasks could be "sourced out" to SourceXChange or CoSource. I think O'Reilly could have some major interest in sponsoring LyX in exchange we could make cls and layouts for the animal series, improve docbook support and XML. Roland On Wed, 23 Feb 2000, Allan Rae wrote: > > I also think it'd be worthwhile to keep this thread running ad infinitum > > with individuals posting whatever snippets from their respective > > subprojects they want included in LDN. That way I don't have to write > > everything myself and hopefully someone else might step forward to act as > > editor. > > Hot topics for next weeks LDN: > + Kayvan and Jacek's RPMs > + double-space? > + GUI-independence (dialogs, libsigc++ + XTL) hopefully reduce the > number of "What's happening? Are you ever going to do anything? > I reckon XForms sucks and you should use blah-tk instead" > + Insets? What's happening with the inset family (ERT, text etc.) > > Maybe I should just settle on several small news items and one feature > area per fortnight. So I'd feature either GUI-indep or Insets depending > on which one of them gets written in time (Jürgen or Lars could you > scribble a couple of paragraphs or provide a copy of an old email you > think would suit). > > We still need someone to gather together the threads of discussion about > mini-projects like citations (natbib, harvard etc. support), pdflatex, > layout file extensions and any number of other areas so we can have a > mini-project page and maybe snare us some new talent. > > Allan. (ARRae)
Re: How to apply a patch?
On Tue, 22 Feb 2000, Claus Hentschel wrote: I've fetched lyx-1.1.4fix1.gz from the official web site. How can I patch my source files using the included text file? cd where lyx devel dir lives patch patchfile or patch -p0 patchfile if in doubt: man patch :-) Roland Thanks in advance Claus
Re: Problems with new Painter/Workarea!
On Tue, 22 Feb 2000, you wrote: Sure I'll have to wait till Alan merges his code otherwise he has a lot more clashes then already and he is already working on it :) Alan, are you waiting for me to move some more of the Dialogs? I started with the Paragraph layout and was hoping to do some more on this weekend. But I can wait and make these changes against 1.1.5cvs. Actually I'd prefer to do that. Roland Other reasons? Greets Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug Those who claim the dead never return to life haven't ever been around here at quitting time. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: How to apply a patch?
On Tue, 22 Feb 2000, Claus Hentschel wrote: > I've fetched lyx-1.1.4fix1.gz from the official web site. How can I patch my > source files using the included text file? cd patch < patchfile or patch -p0 < patchfile if in doubt: man patch :-) Roland > > Thanks in advance > Claus
Re: Problems with new Painter/Workarea!
On Tue, 22 Feb 2000, you wrote: > > Sure I'll have to wait till Alan merges his code otherwise he has a lot > more clashes then already and he is already working on it :) > Alan, are you waiting for me to move some more of the Dialogs? I started with the Paragraph layout and was hoping to do some more on this weekend. But I can wait and make these changes against 1.1.5cvs. Actually I'd prefer to do that. Roland > Other reasons? > > Greets Jürgen > > -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ > > Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] > Italienallee 13/N Tel:+39-0471-450260 > I-39100 Bozen Fax:+39-0471-450296 > ITALY Web:http://www.sad.it/~jug > > Those who claim the dead never return to life haven't ever been around > here at quitting time. > > -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: LyX Development News
Allan Rae wrote: Does SourceForge automatically archive monthly installments so the web page doesn't end up a mile long? Allan. Dont know but I would expect so, I guess you can configure your site there quite a bit if you know how. Roland -- Dr.-Ing. Roland Krause Engineering Software Research and Development Inc, Saint Louis, MO voice: (314) 983 0649-12
Re: LyX Development News
Allan Rae wrote: > Does SourceForge automatically archive monthly installments so the web > page doesn't end up a mile long? > Allan. Dont know but I would expect so, I guess you can configure your site there quite a bit if you know how. Roland -- Dr.-Ing. Roland Krause Engineering Software Research and Development Inc, Saint Louis, MO voice: (314) 983 0649-12
Re: LyX Development News
Good job, the project really needs some regular news/PR. Even if it is just one paragraph every two weeks. B.t.w. When I read through the PR, I realized that actually the new versioning scheme maps 1:1 to the old one. There isnt really any difference except that releases are more often and the release number stays lower. Say that 1.1.4 were version 1.2, development is in 1.1.5cvs, fixes go in 1.1.4fix1. which would be 1.2.1 If a cvs version becomes a release candidate it becomes 1.1.5pre1 this would be 1.3.1. Then 1.1.5 would be released from CVS becoming 1.4 and so on. There isnt really any difference in the procedure except that releases are made more often. i.e. development increments are smaller. There arent too many ways to scin a cat, they say here... Roland Allan Rae wrote: We made it into lwn. Although it now looks like I'm committed to maintaining a "LyX Development News" summary every so often. Allan. (ARRae) -- Dr.-Ing. Roland Krause Engineering Software Research and Development Inc, Saint Louis, MO voice: (314) 983 0649-12
Re: new painter, try cvs.
Hmm, I was able to build yesterdays version from cvs without any problems after running autogen.sh and unapplying a patch that had made it in and caused problems. My system is a Mandrake-7 with gcc-2.95.2. Btw: does anybody whether the latest STL that comes with gcc-2.95.2 supports stringstream? Roland "Kayvan A. Sylvan" wrote: On Wed, Feb 16, 2000 at 06:49:46PM +0100, Lars Gullik Bjønnes wrote: Since the new painter now has been set as default in cvs, I'd be grateful if you (yes, you), could take the time to try out the current cvs, and report any problems related to the painter. These problems will show themselves as lines/chars drawn incorrectly on screen, note that the accentinset are not very good right now (I am working on that). Please report success and failures alike. If everything seems to be ok I will begin to remove the old code, and then the rae branch could sync and to gui indep work would commence. Here's what happens when I try to build from CVS. g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -I/usr/X11R6/include -O2 -m486 -fno-strength-reduce -ansi -Wall -W -pedantic -c formula.C -o formula.o In file included from ../../src/insets/lyxinset.h:22, from formula.h:24, from formula.C:25: ../../src/lyxfont.h:23: direction.h: No such file or directory In file included from ../../src/undo.h:19, from ../../src/BufferView.h:22, from formula.C:32: ../../src/lyxparagraph.h:28: direction.h: No such file or directory formula.C:289: warning: ANSI C does not allow `#warning' formula.C:289: warning: #warning What conversion should be done for s[i] here? -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory -- Dr.-Ing. Roland Krause Engineering Software Research and Development Inc, Saint Louis, MO voice: (314) 983 0649-12
Re: LyX Development News
There is a section news on the homepage. There could be a section development news directly underneath it This would do the trick along with a way simple way to post a story. SourceForge does all that stuff for you... Roland Allan Rae wrote: On 17 Feb 2000, Jean-Marc Lasgouttes wrote: "Allan" == Allan Rae [EMAIL PROTECTED] writes: Allan We made it into lwn. Although it now looks like I'm committed Allan to maintaining a "LyX Development News" summary every so often. I noticed that too. Having a regular 'news' thing would be a good thing, but I'm not sure what the periodicity should be. I was thinking about this last night and we have quite a backlog of info we can use: various improvements and even FAQs from the two lists. I also think it'd be worthwhile to keep this thread running ad infinitum with individuals posting whatever snippets from their respective subprojects they want included in LDN. That way I don't have to write everything myself and hopefully someone else might step forward to act as editor. One thing that I (or Amir since he's got nothing to do ;-) do need to do is to setup a permanent webpage for LDN on the lyx.org site. Something like: www.lyx.org/LDN/index.html www.lyx.org/LDN/latest.html www.lyx.org/LDN/2217.html latest.html should just immediately redirect to whatever is the current document. That way it'd also be considerably easier to get freshmeat etc. to publish news of LyX since they don't normally accept email news items on web-form-based submissions (then you only need type: "New LDN is out at..."). We also get to lift the project's profile somewhat. Allan. (ARRae) -- Dr.-Ing. Roland Krause Engineering Software Research and Development Inc, Saint Louis, MO voice: (314) 983 0649-12
Re: LyX Development News
Good job, the project really needs some regular news/PR. Even if it is just one paragraph every two weeks. B.t.w. When I read through the PR, I realized that actually the new versioning scheme maps 1:1 to the old one. There isnt really any difference except that releases are more often and the release number stays lower. Say that 1.1.4 were version 1.2, development is in 1.1.5cvs, fixes go in 1.1.4fix1. which would be 1.2.1 If a cvs version becomes a release candidate it becomes 1.1.5pre1 this would be 1.3.1. Then 1.1.5 would be released from CVS becoming 1.4 and so on. There isnt really any difference in the procedure except that releases are made more often. i.e. development increments are smaller. There arent too many ways to scin a cat, they say here... Roland Allan Rae wrote: > We made it into lwn. Although it now looks like I'm committed to > maintaining a "LyX Development News" summary every so often. > > Allan. (ARRae) -- Dr.-Ing. Roland Krause Engineering Software Research and Development Inc, Saint Louis, MO voice: (314) 983 0649-12
Re: new painter, try cvs.
Hmm, I was able to build yesterdays version from cvs without any problems after running autogen.sh and unapplying a patch that had made it in and caused problems. My system is a Mandrake-7 with gcc-2.95.2. Btw: does anybody whether the latest STL that comes with gcc-2.95.2 supports stringstream? Roland "Kayvan A. Sylvan" wrote: > On Wed, Feb 16, 2000 at 06:49:46PM +0100, Lars Gullik Bjønnes wrote: > > > > Since the new painter now has been set as default in cvs, I'd be > > grateful if you (yes, you), could take the time to try out the current > > cvs, and report any problems related to the painter. These problems > > will show themselves as lines/chars drawn incorrectly on screen, note > > that the accentinset are not very good right now (I am working on > > that). > > > > Please report success and failures alike. > > If everything seems to be ok I will begin to remove the old code, and > > then the rae branch could sync and to gui indep work would commence. > > Here's what happens when I try to build from CVS. > > g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -I/usr/X11R6/include >-O2 -m486 -fno-strength-reduce -ansi -Wall -W -pedantic -c formula.C -o formula.o > In file included from ../../src/insets/lyxinset.h:22, > from formula.h:24, > from formula.C:25: > ../../src/lyxfont.h:23: direction.h: No such file or directory > In file included from ../../src/undo.h:19, > from ../../src/BufferView.h:22, > from formula.C:32: > ../../src/lyxparagraph.h:28: direction.h: No such file or directory > formula.C:289: warning: ANSI C does not allow `#warning' > formula.C:289: warning: #warning What conversion should be done for s[i] here? > > -- > Kayvan A. Sylvan | Proud husband of | Father to my kids: > Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena > http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory -- Dr.-Ing. Roland Krause Engineering Software Research and Development Inc, Saint Louis, MO voice: (314) 983 0649-12
Re: LyX Development News
There is a section news on the homepage. There could be a section development news directly underneath it This would do the trick along with a way simple way to post a story. SourceForge does all that stuff for you... Roland Allan Rae wrote: > On 17 Feb 2000, Jean-Marc Lasgouttes wrote: > > > >>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: > > > > Allan> We made it into lwn. Although it now looks like I'm committed > > Allan> to maintaining a "LyX Development News" summary every so often. > > > > I noticed that too. Having a regular 'news' thing would be a good > > thing, but I'm not sure what the periodicity should be. > > I was thinking about this last night and we have quite a backlog of info > we can use: various improvements and even FAQs from the two lists. I > also think it'd be worthwhile to keep this thread running ad infinitum > with individuals posting whatever snippets from their respective > subprojects they want included in LDN. That way I don't have to write > everything myself and hopefully someone else might step forward to act as > editor. > > One thing that I (or Amir since he's got nothing to do ;-) do need to do > is to setup a permanent webpage for LDN on the lyx.org site. Something > like: > www.lyx.org/LDN/index.html > www.lyx.org/LDN/latest.html > www.lyx.org/LDN/2217.html > > latest.html should just immediately redirect to whatever is the current > document. > > That way it'd also be considerably easier to get freshmeat etc. to > publish news of LyX since they don't normally accept email news items on > web-form-based submissions (then you only need type: "New LDN is out > at..."). We also get to lift the project's profile somewhat. > > Allan. (ARRae) -- Dr.-Ing. Roland Krause Engineering Software Research and Development Inc, Saint Louis, MO voice: (314) 983 0649-12
Re: Changes made for Win98
What do you mean by "a real Windows executable"? cygwin does just that - it produces a real executable. On NT, the problem with inlined figures is not the forking, forking maybe a kludge but it seems to actually work, the problem is, that you need a ghostscript executable with X11 support. Alladin for Windows has gswin32c which is a commandline ghostscript interpreter, but it does not have X11 support. Otoh it is not really worth spending much time on this, because the whole procedure is a kludge and nothing else. It took months to get it halfway reliable on Linux and sometimes I still notice hanging gs clients ... It will have to be rewritten - and as I know these guys here - it will be rewritten. Roland Andre Poenitz wrote: I tried to use the mingw32 environment on Win98, too to produce a real Win-Executable. *scratch head* I'd like to try that, too... but: How does one specify the usage of a certain compiler when running ./configure? For my own project I use mingw32 for crosscompiling from Linux to Windows, but I handle that using hard-coded paths to the respective compilers (standard gcc for Linux-Linux, //mingw32/..gcc for Linux-Windows) in the (handwritten) Makefile. When I configure LyX, naturally the standard compiler is found (the other is not even in the $PATH). So how to I access my mingw32 "properly"? If someone could enlighten me, please ;-) Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Changes made for Win98
What do you mean by "a real Windows executable"? cygwin does just that - it produces a real executable. On NT, the problem with inlined figures is not the forking, forking maybe a kludge but it seems to actually work, the problem is, that you need a ghostscript executable with X11 support. Alladin for Windows has gswin32c which is a commandline ghostscript interpreter, but it does not have X11 support. Otoh it is not really worth spending much time on this, because the whole procedure is a kludge and nothing else. It took months to get it halfway reliable on Linux and sometimes I still notice hanging gs clients ... It will have to be rewritten - and as I know these guys here - it will be rewritten. Roland Andre Poenitz wrote: > > I tried to use the mingw32 environment on Win98, too to produce a real >Win-Executable. > > *scratch head* I'd like to try that, too... but: > How does one specify the usage of a certain compiler when running ./configure? > > For my own project I use mingw32 for crosscompiling from Linux to > Windows, but I handle that using hard-coded paths to the respective > compilers (standard gcc for Linux->Linux, //mingw32/..gcc for > Linux->Windows) in the (handwritten) Makefile. > > When I configure LyX, naturally the standard compiler > is found (the other is not even in the $PATH). So how to I access > my mingw32 "properly"? > > If someone could enlighten me, please ;-) > > Andre' > > -- > André Pönitz . [EMAIL PROTECTED]
Re: website
Nazgul's disks finally said goodbye. I have now setup baywatchg to take over nazgul's ip-address (as an alias, so now nazgul.lyx.org and baywatch.lyx.org points to different ip'addrs but same machine). Luckily nazgul only had dns as its task. Why dont we move to SourceForge? They have got plenty of resources. This could be done at least partially. Roland I have a new motherboard P200, that I want to put into nazgul, but since the disks are gone I need some new ones... can take a while. Shameless: http://www.devel.lyx.org/funding.php3 Lgb
Re: website
> Nazgul's disks finally said goodbye. I have now setup baywatchg to > take over nazgul's ip-address (as an alias, so now nazgul.lyx.org and > baywatch.lyx.org points to different ip'addrs but same machine). > Luckily nazgul only had dns as its task. Why dont we move to SourceForge? They have got plenty of resources. This could be done at least partially. Roland > I have a new motherboard P200, that I want to put into nazgul, but > since the disks are gone I need some new ones... can take a while. > > Shameless: http://www.devel.lyx.org/funding.php3 > > Lgb
LyX on NT - ps figures :-(
Ok here we go again. I am trying to get ps figures to get rendered. I have followed the code to the point where gs gets called. That is where the problem starts because the standard gswin32c (this is gs on windows) executable does not have an X11 driver compiled in. I am contemplating to either compile a recent Unix gs on NT or recompile the gs distro with an X11 driver. The latter would mean that I'd have to make that available if others wanted to use it. Question: Wouldnt it be better to generate e.g. png or jpeg format and then insert the jpeg bitmap at the appropriate place since that is what gets done after all anyway? But I also do not understand this code in runqueue() (figinset.C) at this point: int err = execlp(lyxrc-ps_command.c_str(), lyxrc-ps_command.c_str(), "-sDEVICE=x11", "-dNOPAUSE", "-dQUIET", "-dSAFER", rbuf, gbuf, tbuf, p-data-fname.c_str(), "showpage.ps", "quit.ps", "-", 0); This is the call to gs but what will happen next if that is succesful? In my man pages it says that execlp never returns instead takes over the calling process but: Where does it go? Maybe someone could enlighten me on this. Roland
Re: LyX on NT - ps figures :-(
Wouldn't that be just wonderful :-)
"Lars Gullik Bjønnes" wrote:
[...]
This use of gs is something we (I) really want to change. I want us to have
a "subprocess" that converts the image files into the wanted format.
And an InsetFig that asks this "subprocess" for an image.
Preferrably I'd like to have the convertees cached on disk and not in
memory. (ok, sometimes both would be needed.)
Hmmm, under memory restrictions that would be necessary I guess but if the interfaces
and classes are designed right this wouldn't be a real problem in either case.
As part of this change I'd like to make it possible to use all kind of
graphics format with LyX without user intervention.
Yes!!!
The idea is that the InsetFig will be very simple, it should just ask
the GraphicsCache for a image name, the format that it wants it in,
the size aspect, rotatation etc. (as of graphicx.sty) and get an image
object returned from the GraphicsCache. The means he GraphicsCache
uses to provide the correct format does not matter for InsetFig.
InsetFig("foo.png") will f.ex. make GraphicsCache use pngtopnm | \
ppmquant | ppmtoxpm
to make the image to view on screen, and pnmtopnm | pnmtops to create
the image used by latex.
the program "identify" could be used to get the bounding box/image
size from the graphics file.
OK, Who wants to develop this?
Ohh wouldnt that be nice...
If I had enough time but I'll try to help Allan with GUI independence right now. Maybe
after that.
For now there wont be any figures in LyX on NT :-(
Lgb
LyX on NT - ps figures :-(
Ok here we go again. I am trying to get ps figures to get rendered. I have followed the code to the point where gs gets called. That is where the problem starts because the standard gswin32c (this is gs on windows) executable does not have an X11 driver compiled in. I am contemplating to either compile a recent Unix gs on NT or recompile the gs distro with an X11 driver. The latter would mean that I'd have to make that available if others wanted to use it. Question: Wouldnt it be better to generate e.g. png or jpeg format and then insert the jpeg bitmap at the appropriate place since that is what gets done after all anyway? But I also do not understand this code in runqueue() (figinset.C) at this point: int err = execlp(lyxrc->ps_command.c_str(), lyxrc->ps_command.c_str(), "-sDEVICE=x11", "-dNOPAUSE", "-dQUIET", "-dSAFER", rbuf, gbuf, tbuf, p->data->fname.c_str(), "showpage.ps", "quit.ps", "-", 0); This is the call to gs but what will happen next if that is succesful? In my man pages it says that execlp never returns instead takes over the calling process but: Where does it go? Maybe someone could enlighten me on this. Roland
Re: LyX on NT - ps figures :-(
Wouldn't that be just wonderful :-)
"Lars Gullik Bjønnes" wrote:
[...]
> This use of gs is something we (I) really want to change. I want us to have
> a "subprocess" that converts the image files into the wanted format.
> And an InsetFig that asks this "subprocess" for an image.
>
> Preferrably I'd like to have the convertees cached on disk and not in
> memory. (ok, sometimes both would be needed.)
Hmmm, under memory restrictions that would be necessary I guess but if the interfaces
and classes are designed right this wouldn't be a real problem in either case.
> As part of this change I'd like to make it possible to use all kind of
> graphics format with LyX without user intervention.
Yes!!!
> The idea is that the InsetFig will be very simple, it should just ask
> the GraphicsCache for a image name, the format that it wants it in,
> the size aspect, rotatation etc. (as of graphicx.sty) and get an image
> object returned from the GraphicsCache. The means he GraphicsCache
> uses to provide the correct format does not matter for InsetFig.
>
> InsetFig("foo.png") will f.ex. make GraphicsCache use pngtopnm | \
> ppmquant | ppmtoxpm
> to make the image to view on screen, and pnmtopnm | pnmtops to create
> the image used by latex.
> the program "identify" could be used to get the bounding box/image
> size from the graphics file.
>
> OK, Who wants to develop this?
Ohh wouldnt that be nice...
If I had enough time but I'll try to help Allan with GUI independence right now. Maybe
after that.
For now there wont be any figures in LyX on NT :-(
>
> Lgb
Re: libsigc++ doesn't like VPATH compiles
Karl, the sigc++ acconfig.in patch needed to get things to compile correctly on NT, did that go into CVS? Allan could you please include that? Background: libsigc++-0.8.6 does not compile out of the box on cygnus-b20 because there are little issues with the configuration. Karl send me a patch that works and I can also apply the patch to the included sigc++ in lyx-devel, but it'd be easier for me if Allan could include the improved version. Regards Roland
Re: libsigc++ doesn't like VPATH compiles
Karl, the sigc++ acconfig.in patch needed to get things to compile correctly on NT, did that go into CVS? Allan could you please include that? Background: libsigc++-0.8.6 does not compile out of the box on cygnus-b20 because there are little issues with the configuration. Karl send me a patch that works and I can also apply the patch to the included sigc++ in lyx-devel, but it'd be easier for me if Allan could include the improved version. Regards Roland
Re: gui independence
Hi Allan, I wanted to answer earlier, just didnt get to it. I 've seen that you checked in some stuff for the big GUI independence hack, good. Let's see that I can scrap some time to help with this now. First, you were correct, that I hadn't read all about the LyXfunc discussion in the mailing list archive. Now with your explanations though I think I've got a rough idea how things are supposed to be. I agree 100%, this is a step by step process. I'll try to summarize what the necessary steps are her emostly for my own understanding. 1. Take a popup, e.g. paragraphs, find the code in the exisiting code base that creates, updates and deletes this dialog and create a form_paragraphs.[Ch] pair of files, then move the existing code. Compile and see whether is all still works. Or something that might be easier: cp lyx/src/frontends/xforms/form_paragraph.[Ch] As you are removing the old implementation merge in any changes and tidy it all up. There are quite some changes so we'll see how much this actually works, but yes you are in principle right of course. s/Dialog/LyXDialogBase/ ors/Dialog/DialogBase/ There are no create or destroy signals. If a dialog hasn't been shown before it will be created just-in-time. Similarly, the hide could be used to delete[] the dialog. In any case, the destructor should clean up anything that may have been created. See other thread on this. I think we may need a ModalDialogBase for the modal dialogs but that can be decided as we go. Grep is your friend but so is any other cross-referencer. Isnt there an etags goal in the makefiles? [...] All it needs is the addition of the appropriate entries. This is mainly the common bits of code that can accept or return data and perform some action with it. Getting the current paragraphs parameters is one possibility. LyXFunc is the API. Anyone writing a script can access anything that LyXFunc has to offer. So its essential that we ensure that both the scripts and the GUI/TUI frontend and the LyX internals can all use it and that it has a sensible, clean collection of functions. Ok, I'll have to look closer into this. I dont understand how this will be usable for scripting yet but I cant imagine how passing strings is the most convenient method for interaction to the GUI frontend, all these conversion from and too integers floats etc... Well as I said I may understand this better when I actually see it. So with this three steps one dialog is encapsulated. The slots can be called from the menu or by means of the cursor moving to a new paragraph. or by keyboard shortcut, or minibuffer command or even a LyXServer request from some exterenal program/script and for some popups there is also the likelihood of calls from inside the LyX core or other lyxfuncs. They all call a LyXFunc. The LyXFunc consists of: case LFUN_LAYOUT_PARAGRAPH: owner-getPopups.showParagraph(); break; (taken straight from the lyx/src/lyxfunc.C:1081-1083) well, yes, except that you'll have to call a slot of the appropriate DialogBase class, yet you havent passed any parameters to the dialog, I guess I havent understood yet. The dialogs will have to explicitely access data from the kernel on their own. Reread the paragraph and example above. We have at least six different ways of getting stuff to happen in LyX. At least three are likely to want answers or to push data into the system (kernel, ui and lyxserver). On the GUI side it's not a push (and shouldnt be) it is the GUI polling info from the kernel, yes, when writing back it could be a push... more OT in private email. Thanks Roland
Re: Drum roll please...
Tathhh.. Allan, great absolutely, good job. I was able to roll my version over to the sigc-1 branch, although a simple cvs up -r sigc-1 wouldnt checkout the new directories. I had to checkout from scratch. What cvs version is the server running? Ok, I had a look at your example, I am not able to compile it, yet. I have found that you created a container class that is supposed to hold all Dialogs. I would suggest to name that class DialogContainer or something appropriate but not Dialogs, I find this confusing (I think of multiple Dialogs which is not what that class is) but that is ultimatively up to you. Second, I noticed that you put all the signals in this class. Why? They really do not belong there, in fact you dont need them there at all. The Signals belong in the DialogBase class. They shall connect to the virtual methods of the base class: show() hide() and update(). That way you do not have to update Dialogs whenever a new Dialog is introduced. Otherwise you have to constantly update Dialogs and keep track when a new Dialog is introduced. The person who makes a new Dialog does not need to know about the calling mechanism, this can safely be encapsulated from him. Dialogs only needs to povide a way to store these Dialogs (do you see what I mean when I suggest renaming the class?). The question is, whether this class is necessary at all. You could make it - as you did - into a vector of Dialogs, then just store the vector where you've got the class now. One class less and a leaner and clearer design. The only method of this class is a hideAll Signal which can be implemented through a loop, that calls hide for all elements of the vector (generic programming). Last but not least I believe that instead the Signals you can use Slots in the DialogBase class to connect to the virtual methods. Maybe I havent fully understood this system and I'll have to play around with it a bit so bear with me if I am making a fool out of myself here. I will try to compile your code and send a modified version in tomorrow. Awsome job nevertheless Regards Roland On Sun, 30 Jan 2000, Allan Rae wrote: On Sun, 30 Jan 2000, Dr. Ing. Roland Krause wrote: Allan, congrats. Now am I clueless or what , but I cant seem to find the branch on the cvs rep. Or do you have a second private cvs rep? All you need to do Roland is "cvs update" since you already have a checked out copy. Or if you want a diff before you update do a "cvs diff -u". I also forgot to do the tagging after I committed and posted the announcement. That's now done. I'll be tagging this "sigc-1" so if you want a diff of the changes you can get that by: cvs diff -u -j "rae-1" -j "sigc-1" Note that I diidn't put a time on when I'd be tagging the sources ;-) Allan. (ARRae)
Re: gui independence
Hi Allan, I wanted to answer earlier, just didnt get to it. I 've seen that you checked in some stuff for the big GUI independence hack, good. Let's see that I can scrap some time to help with this now. First, you were correct, that I hadn't read all about the LyXfunc discussion in the mailing list archive. Now with your explanations though I think I've got a rough idea how things are supposed to be. > I agree 100%, this is a step by step process. I'll try to summarize what the > necessary steps are her emostly for my own understanding. > 1. Take a popup, e.g. paragraphs, find the code in the exisiting code > base that creates, updates and deletes this dialog and create a > form_paragraphs.[Ch] pair of files, then move the existing code. > Compile and see whether is all still works. Or something that might be easier: cp lyx/src/frontends/xforms/form_paragraph.[Ch] As you are removing the old implementation merge in any changes and tidy it all up. There are quite some changes so we'll see how much this actually works, but yes you are in principle right of course. s/Dialog/LyXDialogBase/ ors/Dialog/DialogBase/ There are no create or destroy signals. If a dialog hasn't been shown before it will be created just-in-time. Similarly, the hide could be used to delete[] the dialog. In any case, the destructor should clean up anything that may have been created. See other thread on this. I think we may need a ModalDialogBase for the modal dialogs but that can be decided as we go. Grep is your friend but so is any other cross-referencer. Isnt there an etags goal in the makefiles? [...] All it needs is the addition of the appropriate entries. This is mainly the common bits of code that can accept or return data and perform some action with it. Getting the current paragraphs parameters is one possibility. LyXFunc is the API. Anyone writing a script can access anything that LyXFunc has to offer. So its essential that we ensure that both the scripts and the GUI/TUI frontend and the LyX internals can all use it and that it has a sensible, clean collection of functions. Ok, I'll have to look closer into this. I dont understand how this will be usable for scripting yet but I cant imagine how passing strings is the most convenient method for interaction to the GUI frontend, all these conversion from and too integers floats etc... Well as I said I may understand this better when I actually see it. > So with this three steps one dialog is encapsulated. The slots can be > called from the menu or by means of the cursor moving to a new > paragraph. or by keyboard shortcut, or minibuffer command or even a LyXServer request from some exterenal program/script and for some popups there is also the likelihood of calls from inside the LyX core or other lyxfuncs. They all call a LyXFunc. The LyXFunc consists of: case LFUN_LAYOUT_PARAGRAPH: owner->getPopups.showParagraph(); break; (taken straight from the lyx/src/lyxfunc.C:1081-1083) well, yes, except that you'll have to call a slot of the appropriate DialogBase class, yet you havent passed any parameters to the dialog, I guess I havent understood yet. The dialogs will have to explicitely access data from the kernel on their own. Reread the paragraph and example above. We have at least six different ways of getting stuff to happen in LyX. At least three are likely to want answers or to push data into the system (kernel, ui and lyxserver). On the GUI side it's not a push (and shouldnt be) it is the GUI polling info from the kernel, yes, when writing back it could be a push... more OT in private email. Thanks Roland
Re: Drum roll please...
Tathhh.. Allan, great absolutely, good job. I was able to roll my version over to the sigc-1 branch, although a simple cvs up -r sigc-1 wouldnt checkout the new directories. I had to checkout from scratch. What cvs version is the server running? Ok, I had a look at your example, I am not able to compile it, yet. I have found that you created a container class that is supposed to hold all Dialogs. I would suggest to name that class DialogContainer or something appropriate but not Dialogs, I find this confusing (I think of multiple Dialogs which is not what that class is) but that is ultimatively up to you. Second, I noticed that you put all the signals in this class. Why? They really do not belong there, in fact you dont need them there at all. The Signals belong in the DialogBase class. They shall connect to the virtual methods of the base class: show() hide() and update(). That way you do not have to update Dialogs whenever a new Dialog is introduced. Otherwise you have to constantly update Dialogs and keep track when a new Dialog is introduced. The person who makes a new Dialog does not need to know about the calling mechanism, this can safely be encapsulated from him. Dialogs only needs to povide a way to store these Dialogs (do you see what I mean when I suggest renaming the class?). The question is, whether this class is necessary at all. You could make it - as you did - into a vector of Dialogs, then just store the vector where you've got the class now. One class less and a leaner and clearer design. The only method of this class is a hideAll Signal which can be implemented through a loop, that calls hide for all elements of the vector (generic programming). Last but not least I believe that instead the Signals you can use Slots in the DialogBase class to connect to the virtual methods. Maybe I havent fully understood this system and I'll have to play around with it a bit so bear with me if I am making a fool out of myself here. I will try to compile your code and send a modified version in tomorrow. Awsome job nevertheless Regards Roland On Sun, 30 Jan 2000, Allan Rae wrote: > On Sun, 30 Jan 2000, Dr. Ing. Roland Krause wrote: > > > Allan, congrats. Now am I clueless or what , but I cant seem to find > > the branch on the cvs rep. Or do you have a second private cvs rep? > > All you need to do Roland is "cvs update" since you already have a checked > out copy. Or if you want a diff before you update do a "cvs diff -u". > > I also forgot to do the tagging after I committed and posted the > announcement. That's now done. > > > > I'll be tagging this "sigc-1" so if you want a diff of the changes > > > you can get that by: cvs diff -u -j "rae-1" -j "sigc-1" > > Note that I diidn't put a time on when I'd be tagging the sources ;-) > > Allan. (ARRae)
Re: libsigc++ integration and gui-indep in LyX
Allan, long post indeed. Allan Rae wrote: I noticed you filed a report to the libsigc++ list. Yes, I havent gotten any replies, I have not subscribed to the list but the issue was: libsigc++ version 0.8.5 compiles and works on cygnus b20 NT version 0.8.6 does not compile due to a faulty configure script. I believe the issue is that configure thinks I am using vc++. Using the old 0.8.5 configure.in to configure and compile 0.8.6 works partially - but god what a mess Still these problems will certainly be overcome so no neeed to worry. I've cut down the number of signal and slot templates that are generated (Signal0-Signal2 only for now -- I don't see any need for more that number of parameters in our code [one return + two parameters] although that may change after a long arguement and much swearing) and we only compile it as a static library that isn't installed. If someone wants a libsigc++ library on their system then they should get the real thing. I do not really see why you are doing this. At present it would be better to not mess with libsigc++, i.e. use that thing out of the box, since that's what it was made for. If, at a later point this would become a real issue I am sure a solution can and will be found. But maybe I am misunderstanding what you were actually doing. All the work on this is being done in the "rae" branch of lyx-devel. I haven't committed it yet but I do have libsigc++ integrated on my machine at home. I have started on building the gui-indep structure and currently have a new Popups and PopupBase (the abstract base class). Ok, I switched the lyx-devel branch over to rae and I am trying to compile it as we speak. I would strongly recommend not to drift too far away from the main devel branch but you know that much better than I do since you already lost lots of your work the last time. The first draft of libsigc++ integration uses a slightly modified version of the libsigc++ configure.in in the sigc++ directory. Hmmm, does NT let you have a directory called "sigc++"? What about OS/2? NT has no problems with directory names. Perhaps, but I want to be sure it's good before making it mainstream. After all I expect the floodgates will open with heaps of people scrambling to force their favourite toolkit to be top-dog and convince us to completely ditch xforms and half the existing codebase. At that point this will hopefully happen - yet I doubt it. As I said before I want to filter the popup work and am trying to get a base where we can have popups from different toolkits co-existing although I don't want to allow a new popup to replace a hardcoded one until the hardcoded one has been made gui-indep. That sounds a bit conusing let me try that again: gui-indep popups from multiple toolkits will be supported but will only be visible once the existing xforms popup has been made gui-indep. I agree 100%, this is a step by step process. I'll try to summarize what the necessary steps are her emostly for my own understanding. 1. Take a popup, e.g. paragraphs, find the code in the exisiting code base that creates, updates and deletes this dialog and create a form_paragraphs.[Ch] pair of files, then move the existing code. Compile and see whether is all still works. 2. Create a class form_paragraphs that inherits from Dialog (the base dialog class, was PopupBase) and the class will the implement the appropriate actions to be taken when the slots for create, show, hide, destroy and update are called. 3. The update method is the most important because right now it is tightly integrated with the GUI stuff. For example, I tried to follow the current path through the code when the paragraphs dialog is shown and found that this is essentially handled in lyx_cb.C (like so many other things too :-). From MenuLayoutParagraph() first UpdateLayoutParagraph() is called. It looks like that in the current view the text cursor knows the paragraph it is currently in and that the paragraph has some properties that are shown in the dialog and can be changed. This isnt a very clean design but it obviously works. I heard somewhere that lyxfunc is the solution to all problems (just like 42) and it could/should be asked here. Currently lyxfunc() doesnt have the fuctionality for that or does it? What role would it play here? So with this three steps one dialog is encapsulated. The slots can be called from the meno or my means of the cursor moving to a new paragraph. A popup retrieves the data it needs from the kernel. Andre described this as a Pull method a few months ago. In fact one is his emails is on my list for inclusion in the docs. Hmm, I missed that email, right now the dialog need direct access to the kernel but that doesn seem bad to me. Oh and the popup will get its info from a LyXFunc. We used to use a separate class called Communicator but I've since decided that was a dumb idea as a LyXFunc will be available to scripts and the outside
Re: libsigc++ integration and gui-indep in LyX
Allan, long post indeed. Allan Rae wrote: > I noticed you filed a report to the libsigc++ list. Yes, I havent gotten any replies, I have not subscribed to the list but the issue was: libsigc++ version 0.8.5 compiles and works on cygnus b20 NT version 0.8.6 does not compile due to a faulty configure script. I believe the issue is that configure thinks I am using vc++. Using the old 0.8.5 configure.in to configure and compile 0.8.6 works partially - but god what a mess Still these problems will certainly be overcome so no neeed to worry. > I've cut down the number of signal and slot templates that are generated > (Signal0-Signal2 only for now -- I don't see any need for more that number > of parameters in our code [one return + two parameters] although that may > change after a long arguement and much swearing) and we only compile it as > a static library that isn't installed. If someone wants a libsigc++ > library on their system then they should get the real thing. I do not really see why you are doing this. At present it would be better to not mess with libsigc++, i.e. use that thing out of the box, since that's what it was made for. If, at a later point this would become a real issue I am sure a solution can and will be found. But maybe I am misunderstanding what you were actually doing. > All the work on this is being done in the "rae" branch of lyx-devel. > I haven't committed it yet but I do have libsigc++ integrated on my > machine at home. I have started on building the gui-indep structure and > currently have a new Popups and PopupBase (the abstract base class). Ok, I switched the lyx-devel branch over to rae and I am trying to compile it as we speak. I would strongly recommend not to drift too far away from the main devel branch but you know that much better than I do since you already lost lots of your work the last time. > The first draft of libsigc++ integration uses a slightly modified version > of the libsigc++ configure.in in the sigc++ directory. Hmmm, does NT let > you have a directory called "sigc++"? What about OS/2? NT has no problems with directory names. > Perhaps, but I want to be sure it's good before making it mainstream. > After all I expect the floodgates will open with heaps of people > scrambling to force their favourite toolkit to be top-dog and convince us > to completely ditch xforms and half the existing codebase. At that point this will hopefully happen - yet I doubt it. > As I said before I want to filter the popup work and am trying to get a > base where we can have popups from different toolkits co-existing although > I don't want to allow a new popup to replace a hardcoded one until the > hardcoded one has been made gui-indep. That sounds a bit conusing let me > try that again: gui-indep popups from multiple toolkits will be supported > but will only be visible once the existing xforms popup has been made > gui-indep. I agree 100%, this is a step by step process. I'll try to summarize what the necessary steps are her emostly for my own understanding. 1. Take a popup, e.g. paragraphs, find the code in the exisiting code base that creates, updates and deletes this dialog and create a form_paragraphs.[Ch] pair of files, then move the existing code. Compile and see whether is all still works. 2. Create a class form_paragraphs that inherits from Dialog (the base dialog class, was PopupBase) and the class will the implement the appropriate actions to be taken when the slots for create, show, hide, destroy and update are called. 3. The update method is the most important because right now it is tightly integrated with the GUI stuff. For example, I tried to follow the current path through the code when the paragraphs dialog is shown and found that this is essentially handled in lyx_cb.C (like so many other things too :-). >From MenuLayoutParagraph() first UpdateLayoutParagraph() is called. It looks like that in the current view the text cursor knows the paragraph it is currently in and that the paragraph has some properties that are shown in the dialog and can be changed. This isnt a very clean design but it obviously works. I heard somewhere that lyxfunc is the solution to all problems (just like 42) and it could/should be asked here. Currently lyxfunc() doesnt have the fuctionality for that or does it? What role would it play here? So with this three steps one dialog is encapsulated. The slots can be called from the meno or my means of the cursor moving to a new paragraph. > > > A popup retrieves the data it needs from the kernel. Andre described this > > > as a Pull method a few months ago. In fact one is his emails is on my > > > list for inclusion in the docs. Hmm, I missed that email, right now the dialog need direct access to the kernel but that doesn seem bad to me. > Oh and the popup will get its info from a LyXFunc. We used to use a > separate class called Communicator but I've since decided that was a dumb > idea as a LyXFunc will be
ARRae, gui - indep
This message is primarily for Allan, we have been discussing necessary steps on getting the GUI indep stuff off the ground. I have looked a little more into libsigc++ and I would like to experiment with it a bit. Allan, could you set up the necessary directory structure like it was in the old devel branch? I.e. there was a directory src/frontends with some subdirectories, not all will be necessary but forms for the "beloved" xforms library and qt as well as mfc would be nice. Also, I dont understand what the Communicator class was supposed to do. Is it kind of a mediator between the LyX kernel and the popups? Will it become obsolete with the using of signal/slot? Now, last but not least, I could use some hints with the following. Say I wanted to compile and link LyX with libsigc++, where do I need to make changes so that a) the compiler will find the header files b) the linker will find the library ??? Lets get this baby off the ground. Roland
ARRae, gui - indep
This message is primarily for Allan, we have been discussing necessary steps on getting the GUI indep stuff off the ground. I have looked a little more into libsigc++ and I would like to experiment with it a bit. Allan, could you set up the necessary directory structure like it was in the old devel branch? I.e. there was a directory src/frontends with some subdirectories, not all will be necessary but forms for the "beloved" xforms library and qt as well as mfc would be nice. Also, I dont understand what the Communicator class was supposed to do. Is it kind of a mediator between the LyX kernel and the popups? Will it become obsolete with the using of signal/slot? Now, last but not least, I could use some hints with the following. Say I wanted to compile and link LyX with libsigc++, where do I need to make changes so that a) the compiler will find the header files b) the linker will find the library ??? Lets get this baby off the ground. Roland
What happened to -width option ?
Are -width an d-height depreciated? And if so, why? The current developer version doesnt recognize these options anymore. Is there any reason for it? Roland
bmtable.c and bmtable.C
There seem to be two versions of bmtable.C in the repository. Braindead windows is not case sensitive (welcome to the 21'st century Mr. Gates) and cvs therfore complains to move bmtable.c out of the way whenever I try to get a cvs update. Roland
Re: a view dvi patch for NT
I have seen your subst() function but I did not use it because I thought that you wanted to switch to STL algorithms as much as possible. The LSubString class could be extended but you'd have to decide what to do if the substring isnt present. Do you want to append something to the original string? Why? Shouldn't this be decided on a case to case basis? Ok while we are at it, what is LSubstring intended for in the first place? It can not be in heavy use afaik, I believe there are four files, LaTeX.C, chset.C, vc-backend.C and LSubstring.[Ch]where it is used. I think it was intended to integrate LRegex right? Otherwise it wouldnt make much sense indeed. You can do everything with find() and replace() I also believe the following constructor: LSubstring::LSubstring(string s, LRegex const r) should set n and pos to string::npos if the LRegex wasnt found. I would therefore recommend to leave things in the patch as they are, because the implementation shows clearly what I intended which is: find the substring $$FName if it exists replace it with the actual filename else append the actual filename Roland Jean-Marc Lasgouttes wrote: "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars LSubString foo(command, "$$FNAME"); for a command that does not Lars contain a $$FNAME would not be a valid substring. Lars So everything you do with it will fail/throw/abort etc. So I cannot use substrings unless I know the substring is present? This makes the class much less interesting, since I'll have to do a find() anyway... Would it be possible to change the class (not right now) to work even when the string has not been found (which subst() does quite well, by the way)? JMarc
What happened to -width option ?
Are -width an d-height depreciated? And if so, why? The current developer version doesnt recognize these options anymore. Is there any reason for it? Roland
bmtable.c and bmtable.C
There seem to be two versions of bmtable.C in the repository. Braindead windows is not case sensitive (welcome to the 21'st century Mr. Gates) and cvs therfore complains to move bmtable.c out of the way whenever I try to get a cvs update. Roland
Re: a view dvi patch for NT
I have seen your subst() function but I did not use it because I thought that you wanted to switch to STL algorithms as much as possible. The LSubString class could be extended but you'd have to decide what to do if the substring isnt present. Do you want to append something to the original string? Why? Shouldn't this be decided on a case to case basis? Ok while we are at it, what is LSubstring intended for in the first place? It can not be in heavy use afaik, I believe there are four files, LaTeX.C, chset.C, vc-backend.C and LSubstring.[Ch]where it is used. I think it was intended to integrate LRegex right? Otherwise it wouldnt make much sense indeed. You can do everything with find() and replace() I also believe the following constructor: LSubstring::LSubstring(string & s, LRegex const & r) should set n and pos to string::npos if the LRegex wasnt found. I would therefore recommend to leave things in the patch as they are, because the implementation shows clearly what I intended which is: find the substring $$FName if it exists replace it with the actual filename else append the actual filename Roland Jean-Marc Lasgouttes wrote: > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > > Lars> LSubString foo(command, "$$FNAME"); for a command that does not > Lars> contain a $$FNAME would not be a valid substring. > > Lars> So everything you do with it will fail/throw/abort etc. > > So I cannot use substrings unless I know the substring is present? > This makes the class much less interesting, since I'll have to do a > find() anyway... Would it be possible to change the class (not right > now) to work even when the string has not been found (which subst() > does quite well, by the way)? > > JMarc
a view dvi patch for NT
Hi guys,
here is the promised patch that does two things.
1 It allows for $$FName in \view_dvi_command and \view_ps_command so that on
NT/95 you can put
\view_dvi_command "yap `cygpath -w $$FName`"
and resp.
\view_ps_command "gsview32 `cygpath -w $$FName`"
in your lyxrc file. This removes the need for a startup script dvi.bat and
gv.bat on windows platforms.
2 It introduces
\view_dvi_paper_option ""
also in lyxrc. With this option you can overwrite the papersize that is
specified when viewing a dvi file.
yap (the MikTeX dvi viewer) doesnt have a paper option at all, so you get an
error message when viewing a dvi file.
When this option is set to blank, i.e. "", no paper size is specified when yap
is called. If this command is not given at all
nothing is changed.
I hope that this can be include in the 1.1.4 release and that I didnt introduce
side effects because I had to rearrange the dvi preview method a bit.
Let me know it this can go in or if I need to change something.
Roland
Index: lyx-devel/src/lyx_cb.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_cb.C,v
retrieving revision 1.38
diff -u -r1.38 lyx_cb.C
--- lyx-devel/src/lyx_cb.C 2000/01/11 01:59:00 1.38
+++ lyx-devel/src/lyx_cb.C 2000/01/21 19:10:52
@@ -514,8 +514,20 @@
path = buffer-tmppath;
}
Path p(path);
-
- cmd = command + ' ' + QuoteName(name);
+ /*
+* At this point we check whether the command contains the filename
+parameter
+* $$FName and if that's the case we substitute the real file name
+otherwise
+* the filename is simply appended.
+* rokrau 1/12/00
+*/
+ cmd = command;
+ std::string::size_type i;
+ if ( (i=command.find("$$FName")) != std::string::npos)
+ {
+ cmd.replace(i,7,QuoteName(name));
+ }
+ else
+ cmd = command + ' ' + QuoteName(name);
Systemcalls one;
@@ -712,59 +724,58 @@
// Who cares?
//if (!bv-text)
// return false;
-
- string paper;
-
- // wrong type
- char real_papersize = buffer-params.papersize;
- if (real_papersize == BufferParams::PAPER_DEFAULT)
- real_papersize = lyxrc-default_papersize;
-
- switch (real_papersize) {
- case BufferParams::PAPER_USLETTER:
- paper = "us";
- break;
- case BufferParams::PAPER_A3PAPER:
- paper = "a3";
- break;
- case BufferParams::PAPER_A4PAPER:
- paper = "a4";
- break;
- case BufferParams::PAPER_A5PAPER:
- paper = "a5";
- break;
- case BufferParams::PAPER_B5PAPER:
- paper = "b5";
- break;
- case BufferParams::PAPER_EXECUTIVEPAPER:
- paper = "foolscap";
- break;
- case BufferParams::PAPER_LEGALPAPER:
- paper = "legal";
- break;
- default: /* If nothing else fits, keep the empty value */
- break;
- }
+ string paper = lyxrc-view_dvi_paper_option;
+ if (!paper.empty()) {
+ // wrong type
+ char real_papersize = buffer-params.papersize;
+ if (real_papersize == BufferParams::PAPER_DEFAULT)
+ real_papersize = lyxrc-default_papersize;
- if (paper.empty()) {
- if (buffer-params.orientation == BufferParams::ORIENTATION_LANDSCAPE)
- // we HAVE to give a size when the page is in
- // landscape, so use USletter.
- paper = " -paper usr";
- } else {
- paper = " -paper " + paper;
- if (buffer-params.orientation == BufferParams::ORIENTATION_LANDSCAPE)
- paper+= 'r';
+ switch (real_papersize) {
+ case BufferParams::PAPER_USLETTER:
+ paper += " us";
+ break;
+ case BufferParams::PAPER_A3PAPER:
+ paper += " a3";
+ break;
+ case BufferParams::PAPER_A4PAPER:
+ paper += " a4";
+ break;
+ case BufferParams::PAPER_A5PAPER:
+ paper += " a5";
+ break;
+ case BufferParams::PAPER_B5PAPER:
+ paper += " b5";
+ break;
+ case BufferParams::PAPER_EXECUTIVEPAPER:
+ paper += " foolscap";
+ break;
+ case BufferParams::PAPER_LEGALPAPER:
+ paper += " legal";
+ break;
a view dvi patch for NT
Hi guys,
here is the promised patch that does two things.
1 It allows for $$FName in \view_dvi_command and \view_ps_command so that on
NT/95 you can put
\view_dvi_command "yap `cygpath -w $$FName`"
and resp.
\view_ps_command "gsview32 `cygpath -w $$FName`"
in your lyxrc file. This removes the need for a startup script dvi.bat and
gv.bat on windows platforms.
2 It introduces
\view_dvi_paper_option ""
also in lyxrc. With this option you can overwrite the papersize that is
specified when viewing a dvi file.
yap (the MikTeX dvi viewer) doesnt have a paper option at all, so you get an
error message when viewing a dvi file.
When this option is set to blank, i.e. "", no paper size is specified when yap
is called. If this command is not given at all
nothing is changed.
I hope that this can be include in the 1.1.4 release and that I didnt introduce
side effects because I had to rearrange the dvi preview method a bit.
Let me know it this can go in or if I need to change something.
Roland
Index: lyx-devel/src/lyx_cb.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_cb.C,v
retrieving revision 1.38
diff -u -r1.38 lyx_cb.C
--- lyx-devel/src/lyx_cb.C 2000/01/11 01:59:00 1.38
+++ lyx-devel/src/lyx_cb.C 2000/01/21 19:10:52
@@ -514,8 +514,20 @@
path = buffer->tmppath;
}
Path p(path);
-
- cmd = command + ' ' + QuoteName(name);
+ /*
+* At this point we check whether the command contains the filename
+parameter
+* $$FName and if that's the case we substitute the real file name
+otherwise
+* the filename is simply appended.
+* rokrau 1/12/00
+*/
+ cmd = command;
+ std::string::size_type i;
+ if ( (i=command.find("$$FName")) != std::string::npos)
+ {
+ cmd.replace(i,7,QuoteName(name));
+ }
+ else
+ cmd = command + ' ' + QuoteName(name);
Systemcalls one;
@@ -712,59 +724,58 @@
// Who cares?
//if (!bv->text)
// return false;
-
- string paper;
-
- // wrong type
- char real_papersize = buffer->params.papersize;
- if (real_papersize == BufferParams::PAPER_DEFAULT)
- real_papersize = lyxrc->default_papersize;
-
- switch (real_papersize) {
- case BufferParams::PAPER_USLETTER:
- paper = "us";
- break;
- case BufferParams::PAPER_A3PAPER:
- paper = "a3";
- break;
- case BufferParams::PAPER_A4PAPER:
- paper = "a4";
- break;
- case BufferParams::PAPER_A5PAPER:
- paper = "a5";
- break;
- case BufferParams::PAPER_B5PAPER:
- paper = "b5";
- break;
- case BufferParams::PAPER_EXECUTIVEPAPER:
- paper = "foolscap";
- break;
- case BufferParams::PAPER_LEGALPAPER:
- paper = "legal";
- break;
- default: /* If nothing else fits, keep the empty value */
- break;
- }
+ string paper = lyxrc->view_dvi_paper_option;
+ if (!paper.empty()) {
+ // wrong type
+ char real_papersize = buffer->params.papersize;
+ if (real_papersize == BufferParams::PAPER_DEFAULT)
+ real_papersize = lyxrc->default_papersize;
- if (paper.empty()) {
- if (buffer->params.orientation == BufferParams::ORIENTATION_LANDSCAPE)
- // we HAVE to give a size when the page is in
- // landscape, so use USletter.
- paper = " -paper usr";
- } else {
- paper = " -paper " + paper;
- if (buffer->params.orientation == BufferParams::ORIENTATION_LANDSCAPE)
- paper+= 'r';
+ switch (real_papersize) {
+ case BufferParams::PAPER_USLETTER:
+ paper += " us";
+ break;
+ case BufferParams::PAPER_A3PAPER:
+ paper += " a3";
+ break;
+ case BufferParams::PAPER_A4PAPER:
+ paper += " a4";
+ break;
+ case BufferParams::PAPER_A5PAPER:
+ paper += " a5";
+ break;
+ case BufferParams::PAPER_B5PAPER:
+ paper += " b5";
+ break;
+ case BufferParams::PAPER_EXECUTIVEPAPER:
+ paper += " foolscap";
+ break;
+ case BufferParams::PAPER_LEGALPAPER:
+ paper += " legal";
+
Re: LyX CVS access problem
Yes I am, I need to download libsigc++ and try to get familiar with it. Will do so later today. I first need to try to get the latest CVS to run on NT. Roland Allan Rae wrote: On 19 Jan 2000, Lars Gullik Bjønnes wrote: Allan Rae [EMAIL PROTECTED] writes: | On another interesting note my supervisor is away for the next two weeks | but he made me repeat after him: "I will not work on LyX" But you crossed your fingers right? And my toes! I do really need to get some work done on my thesis though... eventually. I've attached a patch against the old lyx devel stream that converts it to use libsigc++. I did this for two main reasons: it gave me a chance to test libsigc++'s gtk--sig.h wrapper against a known working app (at least the bits related to signals/slots anyway) and it also means the repository shows the correct form of using libsigc++ rather than the older gtk-- signal system. Differences are fairly minor although I'm also submitting a patch to Karl (of libsigc++) that fixes a few problems with their gtk--sig.h. So, even if you don't want this applied to the repository any potential gui-indep people are likely to need it. Roland are you still keen? Allan. (ARRae) Name: arrae-2120.patch.gz arrae-2120.patch.gz Type: PATCH File (application/x-unknown-content-type-patch_auto_file) Encoding: BASE64 Description: apply to the _old_ lyx devel repository: cvs lyx
Re: LyX CVS access problem
Yes I am, I need to download libsigc++ and try to get familiar with it. Will do so later today. I first need to try to get the latest CVS to run on NT. Roland Allan Rae wrote: > On 19 Jan 2000, Lars Gullik Bjønnes wrote: > > > Allan Rae <[EMAIL PROTECTED]> writes: > > > > | On another interesting note my supervisor is away for the next two weeks > > | but he made me repeat after him: "I will not work on LyX" > > > > But you crossed your fingers right? > > And my toes! I do really need to get some work done on my thesis > though... eventually. > > I've attached a patch against the old lyx devel stream that converts it to > use libsigc++. I did this for two main reasons: it gave me a chance to > test libsigc++'s gtk--sig.h wrapper against a known working app (at least > the bits related to signals/slots anyway) and it also means the repository > shows the correct form of using libsigc++ rather than the older gtk-- > signal system. Differences are fairly minor although I'm also submitting > a patch to Karl (of libsigc++) that fixes a few problems with their > gtk--sig.h. > > So, even if you don't want this applied to the repository any potential > gui-indep people are likely to need it. Roland are you still keen? > > Allan. (ARRae) > > > Name: arrae-2120.patch.gz >arrae-2120.patch.gz Type: PATCH File >(application/x-unknown-content-type-patch_auto_file) > Encoding: BASE64 > Description: apply to the _old_ lyx devel repository: cvs >lyx
Re: GUI indep, MathML/TeX, xml code reuse possibilities
Ok its Friday and I am in the mood for trouble, so I ask - Why GUI independence ? What's the point of GUI independence, why not instead focussing on a) moving away from XForms, because - XForms is insufficient for our long term needs, XForms technology is simple but doesn't really provide as much functionality as most modern toolkits. Drag and drop as well as cut and paste will probably never be implemented satisfactory. XForms has many other disadvantages though it is fast and simple. Interoperability with Gtk, Motif, Qt/KDE or (g.h.u.) Windows seem unthinkable today with XForms. - With such a small developer team and so much of a project, the toolkit should really be as sofisticated as possible. One should make up ones mind whether the goal is to have a nice, well functioning application or whether the goal is to implement large blocks if basic fuctionality (e.g. Signal/Slot) that is actually better implemented in a toolkit. XForms deficiencies are the reason for developers having to work around. - XForms scares potential developers and potential users away. It is the sole reason LyX isnt shipped with RedHat nor with Mandrake nor Suse (afaik) (dont know about Debian). - It is non free and therefore inferior to most other toolkits, it is impossible to fix bugs and to implement missing features. - There is no noticable development anymore, the website goes down for weeks on end, the whole project seems dead to me somehow. b) pushing the no-GUI version of LyX, i.e. lyx --export latex foo.lyx, or better pushing towards XML - it is an illusion to think that an ncurses version really makes sense, it is a very marginal feature that blocks development. Instead what people have asked for many times is the translation feature. Actually with switching to XML and an appropriate LyX DTD and LaTeX XSL or CSS this would come automatically. c) decide on a well supported, possibly cross platform alternative toolkit. - wxwin is very promising with respect to cross platform, it has many features but is also missing some functionality - Gtk+, since everybody knows this one and there is also a least a Windows hack available - Qt/KDE is objectively the best toolkit available today. There are even IDE's available for the GUI stuff d) alternative to c) pick up/take over KLyX and try to merge LyX into KLyX and dump XForms asap. KLyX is afaik not actively developed anymore, the mailing list is close to dead and I think Jochen is the only person working on it occasionally (right Jochen?). What do yall think ? Juergen Vigna wrote: On 14-Jan-2000 Allan Rae wrote: It is probably a mistake to look at LyX internals when defining a new file format. If for no other reason than that we still fully intend to merge Asger's kernel and all the new Insets from the old devel branch. In fact it might be wiser to either just study the Inset family from the old devel branch to see where we are headed or better yet help backport those insets. In particular the InsetText and InsetERT stuff would be _major_ wins if we can get those in soon. I just wanted to do this for a long time now, but I've to wait till we backport the Painter and PainterBackend as this is the base for the insets in the old devel-branch. So we have to start the GUI independence first! In regard to the new file format it's just impossible to introduce something decent now for tabulars it will be only possible after having a tabular- inset. Obviously we can have a tabular[all the tabular file format ASIS] /tabular :) Greets Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug Ah say, son, you're about as sharp as a bowlin' ball. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: GUI indep, MathML/TeX, xml code reuse possibilities
Ok its Friday and I am in the mood for trouble, so I ask - Why GUI independence ? What's the point of GUI independence, why not instead focussing on a) moving away from XForms, because - XForms is insufficient for our long term needs, XForms technology is simple but doesn't really provide as much functionality as most modern toolkits. Drag and drop as well as cut and paste will probably never be implemented satisfactory. XForms has many other disadvantages though it is fast and simple. Interoperability with Gtk, Motif, Qt/KDE or (g.h.u.) Windows seem unthinkable today with XForms. - With such a small developer team and so much of a project, the toolkit should really be as sofisticated as possible. One should make up ones mind whether the goal is to have a nice, well functioning application or whether the goal is to implement large blocks if basic fuctionality (e.g. Signal/Slot) that is actually better implemented in a toolkit. XForms deficiencies are the reason for developers having to work around. - XForms scares potential developers and potential users away. It is the sole reason LyX isnt shipped with RedHat nor with Mandrake nor Suse (afaik) (dont know about Debian). - It is non free and therefore inferior to most other toolkits, it is impossible to fix bugs and to implement missing features. - There is no noticable development anymore, the website goes down for weeks on end, the whole project seems dead to me somehow. b) pushing the no-GUI version of LyX, i.e. lyx --export latex foo.lyx, or better pushing towards XML - it is an illusion to think that an ncurses version really makes sense, it is a very marginal feature that blocks development. Instead what people have asked for many times is the translation feature. Actually with switching to XML and an appropriate LyX DTD and LaTeX XSL or CSS this would come automatically. c) decide on a well supported, possibly cross platform alternative toolkit. - wxwin is very promising with respect to cross platform, it has many features but is also missing some functionality - Gtk+, since everybody knows this one and there is also a least a Windows hack available - Qt/KDE is objectively the best toolkit available today. There are even IDE's available for the GUI stuff d) alternative to c) pick up/take over KLyX and try to merge LyX into KLyX and dump XForms asap. KLyX is afaik not actively developed anymore, the mailing list is close to dead and I think Jochen is the only person working on it occasionally (right Jochen?). What do yall think ? Juergen Vigna wrote: > On 14-Jan-2000 Allan Rae wrote: > > > > It is probably a mistake to look at LyX internals when defining a new > > file format. If for no other reason than that we still fully intend > > to merge Asger's kernel and all the new Insets from the old devel > > branch. In fact it might be wiser to either just study the Inset > > family from the old devel branch to see where we are headed or better > > yet help backport those insets. In particular the InsetText and > > InsetERT stuff would be _major_ wins if we can get those in soon. > > I just wanted to do this for a long time now, but I've to wait till we > backport the Painter and PainterBackend as this is the base for the insets > in the old devel-branch. So we have to start the GUI independence first! > > In regard to the new file format it's just impossible to introduce something > decent now for tabulars it will be only possible after having a tabular- > inset. Obviously we can have a [all the tabular file format ASIS] > :) > > Greets Jürgen > > -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ > > Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] > Italienallee 13/N Tel:+39-0471-450260 > I-39100 Bozen Fax:+39-0471-450296 > ITALY Web:http://www.sad.it/~jug > > Ah say, son, you're about as sharp as a bowlin' ball. > > -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Lyx trouble with MikTeX
Jean-Marc, I finally got to it and made a patch that solves the problem of having to have extra batch files on NT for DVI previewing and PS previewing. It is now possible to specify \view_ps_command "gsview32 `cygpath -w $$FName`" and \view_dvi_command "yap `cygpath -w $$FName`" in your .lyxrc file. I also got rid of the -paper option when the dvi command contains yap although that is bad now that I think about it. When someone names a regular document yap the -paper option will be left out. Hmmm. maybe the whole block in lyx_cb.C needs and #ifdef WIN_NT or we need to make a \view_dvi_nopaper command that explicitly shuts the paper option of. Regards Roland Jean-Marc Lasgouttes wrote: "Roland" == Ing Roland Krause [EMAIL PROTECTED] writes: Roland Jean-Marc, I apologize but what exactly do you need ? Is it a Roland listing of the command line arguments or a tested opening of a Roland document from the commandline using gsview, yap and cygpath ? Hmmm, I was about to answer, and then I realized that it was not as easy, since most configuration commands in lyxrc do not permit to modify the way filenames are passed to commands. If the format for \view_ps_command "ghostview -swap" was \view_ps_command "ghostview -swap $$FName" it would be possible to use \view_ps_command "gsview32 `cygpath $$FName`" as preview command. Hmmm, we really need a good configurable way of invokation of all those things... I do not have much time for it these days, though... but I would gladly accept patches :) JMarc lyx_cb.patch
Re: Lyx trouble with MikTeX
On Wed, 12 Jan 2000, Allan Rae wrote: Does yap have a different parameter for setting paper size or none at all? Afaik it does not have a paper parameter, though its Open Source and someone could get the idea to implement one. I just dont really know what this is for at all. Isnt the paper size information contained in the dvi file? Maybe we need a similar set of lyxrc variables to printing for our viewing: \view_dvi_paper_flag, \view_ps_paper_flag and a couple of others. Something like this should be fairly easy to implement from what I saw today :-) Allan. (ARRae) Roland
Re: Lyx trouble with MikTeX
Jean-Marc, I finally got to it and made a patch that solves the problem of having to have extra batch files on NT for DVI previewing and PS previewing. It is now possible to specify \view_ps_command "gsview32 `cygpath -w $$FName`" and \view_dvi_command "yap `cygpath -w $$FName`" in your .lyxrc file. I also got rid of the -paper option when the dvi command contains yap although that is bad now that I think about it. When someone names a regular document yap the -paper option will be left out. Hmmm. maybe the whole block in lyx_cb.C needs and #ifdef WIN_NT or we need to make a \view_dvi_nopaper command that explicitly shuts the paper option of. Regards Roland Jean-Marc Lasgouttes wrote: > > "Roland" == Ing Roland Krause <[EMAIL PROTECTED]> writes: > > Roland> Jean-Marc, I apologize but what exactly do you need ? Is it a > Roland> listing of the command line arguments or a tested opening of a > Roland> document from the commandline using gsview, yap and cygpath ? > > Hmmm, I was about to answer, and then I realized that it was not as > easy, since most configuration commands in lyxrc do not permit to > modify the way filenames are passed to commands. If the format for > \view_ps_command "ghostview -swap" > was > \view_ps_command "ghostview -swap $$FName" > it would be possible to use > \view_ps_command "gsview32 `cygpath $$FName`" > as preview command. > > Hmmm, we really need a good configurable way of invokation of all > those things... I do not have much time for it these days, though... > but I would gladly accept patches :) > > JMarc lyx_cb.patch
Re: Lyx trouble with MikTeX
On Wed, 12 Jan 2000, Allan Rae wrote: > Does yap have a different parameter for setting paper size or none at all? Afaik it does not have a paper parameter, though its Open Source and someone could get the idea to implement one. I just dont really know what this is for at all. Isnt the paper size information contained in the dvi file? > Maybe we need a similar set of lyxrc variables to printing for our > viewing: \view_dvi_paper_flag, \view_ps_paper_flag and a couple of > others. Something like this should be fairly easy to implement from what I saw today :-) > > Allan. (ARRae) Roland
Re: News from the NT front
On Thu, 06 Jan 2000, you wrote: XOpenIM is used to have proper handling of compose key. However, it seems that X11R6.4 fix04 (??) has a bug which core dumps when XOpenIM is called with NULL arguments. It might be what you are seeing. JMarc You could be right, XOpenIM is called with for aguments, the display is non-NULL but the other three are 0. Now the big question is, what is different when XopenIM is called and the code is started by the startup script, because the it will work. Unfortunately, I am nowhere near the NT box today, actually I am sitting in the delivery room of the hospital waiting for our first baby to be born :-) so I guess I wont have much time to check it out in the near future. Roland
Re: News from the NT front
On Thu, 06 Jan 2000, you wrote: > XOpenIM is used to have proper handling of compose key. However, it > seems that X11R6.4 fix04 (??) has a bug which core dumps when XOpenIM > is called with NULL arguments. It might be what you are seeing. > > JMarc You could be right, XOpenIM is called with for aguments, the display is non-NULL but the other three are 0. Now the big question is, what is different when XopenIM is called and the code is started by the startup script, because the it will work. Unfortunately, I am nowhere near the NT box today, actually I am sitting in the delivery room of the hospital waiting for our first baby to be born :-) so I guess I wont have much time to check it out in the near future. Roland
Re: One more lyx-devel on cygnus NT
Lars, I got an email from the cygwin folks the other day saying that regex (the BSD) version is included in cygwin beta 20. I havent found it there though I havent looked very hard, but before you go through all the hussle I would suggest that I try to find out some more about this. Regards Roland PS: Happy new year - I see we are back in business. "Dr. Ing. Roland Krause" [EMAIL PROTECTED] writes: | So I downloaded it from ftp.gnu.org. I then changed a few lines in | config.status and got LyX to compile ... | ... and after changing I will get that from ftp.gnu.org and include it in the lyx distribution. | But !!! If I use Steven's startup script, then the home directory and | LYX_DIR_10X get set correctly and it starts up und runs just fine. Perhaps we should have this startup script in the distribution too. | Maybe one can include regex with LyX, its small and GNU GPL'ed. Then NT | users can specify | --with-included-regex upon configuration ? | What do you guys think I don't think we need the --with-included-regex switch, we should use the systems one if that is ok and if not use the one we provide. Lgb
More NT fun
Friends, I am trying to find my way through the LyX startup procedure. The overall goal would be to get an NT port that does not need any special startup scripts. So my first step is to try and find out why LyX crashes when it is started from the command line. I've gotten to the point where a DebugStream is instantiated. Then the program dies at 0x5d5ce0 in __builtin_new () at DebugStream.C:194 194 } (gdb) s Cannot access memory at address 0x200. after that I am not able to get a stack trace from gdb anymore but right before I get: (gdb) wher #0 DebugStream::DebugStream (this=0x6158a0, __in_chrg=1, t=NONE) at /cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95. 2/../../../../../include/g++-3/streambuf.h:479 #1 0x4ade62 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ../src/lyx_main.C:40 #2 0x4ae015 in global constructors keyed to lyxserver () at ../src/lastfiles.h:62 #3 0x610033ed in _size_of_stack_reserve__ () #4 0x61004437 in _size_of_stack_reserve__ () #5 0x4e19c1 in main (argc=1, argv=0xa031d70) at ../src/main.C:28 #6 0x61004402 in _size_of_stack_reserve__ () #7 0x61004420 in _size_of_stack_reserve__ () #8 0x5d900e in cygwin_crt0 (f=0x4e19ac main) at /home/noer/src/b20/comp-tools/devo/winsup/libccrt0.cc:81 Well all this does not make sense to me therefore I'd like to ask for a pointer where to look. It is clear to me that the environment variables set in Steven's scripts must play an important role, but where are these variables assessed and imho the program shouldnt crash if they arent there in the first place. Thanks for any pointers Roland (who is positively astonished by the LyX-Code)
the log file DUUHH
Sorry - I forgot to attache the log file. Time to go home... Here it is. ROland ruebe.log
Re: One more lyx-devel on cygnus NT
Lars, I got an email from the cygwin folks the other day saying that regex (the BSD) version is included in cygwin beta 20. I havent found it there though I havent looked very hard, but before you go through all the hussle I would suggest that I try to find out some more about this. Regards Roland PS: Happy new year - I see we are back in business. "Dr. Ing. Roland Krause" <[EMAIL PROTECTED]> writes: | So I downloaded it from ftp.gnu.org. I then changed a few lines in | config.status and got LyX to compile ... | ... and after changing I will get that from ftp.gnu.org and include it in the lyx distribution. | But !!! If I use Steven's startup script, then the home directory and | LYX_DIR_10X get set correctly and it starts up und runs just fine. Perhaps we should have this startup script in the distribution too. | Maybe one can include regex with LyX, its small and GNU GPL'ed. Then NT | users can specify | --with-included-regex upon configuration ? | What do you guys think I don't think we need the --with-included-regex switch, we should use the systems one if that is ok and if not use the one we provide. Lgb
More NT fun
Friends, I am trying to find my way through the LyX startup procedure. The overall goal would be to get an NT port that does not need any special startup scripts. So my first step is to try and find out why LyX crashes when it is started from the command line. I've gotten to the point where a DebugStream is instantiated. Then the program dies at 0x5d5ce0 in __builtin_new () at DebugStream.C:194 194 } (gdb) s Cannot access memory at address 0x200. after that I am not able to get a stack trace from gdb anymore but right before I get: (gdb) wher #0 DebugStream::DebugStream (this=0x6158a0, __in_chrg=1, t=NONE) at /cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/2.95. 2/../../../../../include/g++-3/streambuf.h:479 #1 0x4ade62 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ../src/lyx_main.C:40 #2 0x4ae015 in global constructors keyed to lyxserver () at ../src/lastfiles.h:62 #3 0x610033ed in _size_of_stack_reserve__ () #4 0x61004437 in _size_of_stack_reserve__ () #5 0x4e19c1 in main (argc=1, argv=0xa031d70) at ../src/main.C:28 #6 0x61004402 in _size_of_stack_reserve__ () #7 0x61004420 in _size_of_stack_reserve__ () #8 0x5d900e in cygwin_crt0 (f=0x4e19ac ) at /home/noer/src/b20/comp-tools/devo/winsup/libccrt0.cc:81 Well all this does not make sense to me therefore I'd like to ask for a pointer where to look. It is clear to me that the environment variables set in Steven's scripts must play an important role, but where are these variables assessed and imho the program shouldnt crash if they arent there in the first place. Thanks for any pointers Roland (who is positively astonished by the LyX-Code)
the log file DUUHH
Sorry - I forgot to attache the log file. Time to go home... Here it is. ROland ruebe.log
stubborn me still trying...
to compile the development branch on my NT box.
I have managed to create the initial configure file on a Linux box and
ftp'ed the whole thing over to the NT box.
automake and autoconf seem to be either broken or I have some problems
that I cant figure out.
Anyway, after getting the xforms library from Stevens ftp site
(www.xforms.com seems to be down right now) I managed to get over the
initial configuration step but when the make step gets to compiling
mathed I get a gazillion error messages,
of which I include the first lines here:
It looks like the X11 header files are not ANSI C++ compliant and
therefore should be included in/with an
extern "C" {} construct. Otoh when I give that a quick shot it doesnt
change anything either.
So what I did then was to look into the Xlib.h file and I found that the
function prototypes have a statement like
#if NeedFunctionPrototypes
bla bla bla
#endif
but this seems not the problem, there are function prototypes that do
not declare a return value and that _is_ a problem for an ANSI C++
compiler.
Is there an easy fix for this ?
Thanks a lot for any kinda hints.
Regards
Roland
pcroland:~/Src/C++/lyx-devel/src/mathed 241 make
/bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I../../src -I.
./../images -I./../ -I/usr/local/include-I/usr/X11R6.4/include -g
-O -fno
-rtti -Wall -W -Wconversion -DNeedFunctionPrototypes -c formula.C
g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../
-I/usr/local/incl
ude -I/usr/X11R6.4/include -g -O -fno-rtti -Wall -W -Wconversion
-DNeedFunctionP
rototypes -Wp,-MD,.deps/formula.pp -c formula.C -o formula.o
In file included from /usr/local/include/forms.h:988,
from ../../src/lyxfont.h:18,
from ../../src/insets/lyxinset.h:20,
from formula.h:24,
from formula.C:25:
/usr/X11R6.4/include/X11/Xlib.h:2058: ANSI C++ forbids declaration
`XSetTransien
tForHint' with no type
/usr/X11R6.4/include/X11/Xlib.h:2066: ANSI C++ forbids declaration
`XActivateScr
eenSaver' with no type
/usr/X11R6.4/include/X11/Xlib.h:2073: ANSI C++ forbids declaration
`XAddHost' wi
th no type
/usr/X11R6.4/include/X11/Xlib.h:2081: ANSI C++ forbids declaration
`XAddHosts' w
ith no type
/usr/X11R6.4/include/X11/Xlib.h:2088: ANSI C++ forbids declaration
`XAddToExtens
ionList' with no type
/usr/X11R6.4/include/X11/Xlib.h:2095: ANSI C++ forbids declaration
`XAddToSaveSe
t' with no type
/usr/X11R6.4/include/X11/Xlib.h:2149: ANSI C++ forbids declaration
`XAllowEvents
' with no type
/usr/X11R6.4/include/X11/Xlib.h:2155: ANSI C++ forbids declaration
`XAutoRepeatO
ff' with no type
g++: make: *** [formula.lo] Error 1
stubborn me still trying...
to compile the development branch on my NT box.
I have managed to create the initial configure file on a Linux box and
ftp'ed the whole thing over to the NT box.
automake and autoconf seem to be either broken or I have some problems
that I cant figure out.
Anyway, after getting the xforms library from Stevens ftp site
(www.xforms.com seems to be down right now) I managed to get over the
initial configuration step but when the make step gets to compiling
mathed I get a gazillion error messages,
of which I include the first lines here:
It looks like the X11 header files are not ANSI C++ compliant and
therefore should be included in/with an
extern "C" {} construct. Otoh when I give that a quick shot it doesnt
change anything either.
So what I did then was to look into the Xlib.h file and I found that the
function prototypes have a statement like
#if NeedFunctionPrototypes
bla bla bla
#endif
but this seems not the problem, there are function prototypes that do
not declare a return value and that _is_ a problem for an ANSI C++
compiler.
Is there an easy fix for this ?
Thanks a lot for any kinda hints.
Regards
Roland
pcroland:~/Src/C++/lyx-devel/src/mathed 241 > make
/bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I../../src -I.
./../images -I./../ -I/usr/local/include-I/usr/X11R6.4/include -g
-O -fno
-rtti -Wall -W -Wconversion -DNeedFunctionPrototypes -c formula.C
g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../
-I/usr/local/incl
ude -I/usr/X11R6.4/include -g -O -fno-rtti -Wall -W -Wconversion
-DNeedFunctionP
rototypes -Wp,-MD,.deps/formula.pp -c formula.C -o formula.o
In file included from /usr/local/include/forms.h:988,
from ../../src/lyxfont.h:18,
from ../../src/insets/lyxinset.h:20,
from formula.h:24,
from formula.C:25:
/usr/X11R6.4/include/X11/Xlib.h:2058: ANSI C++ forbids declaration
`XSetTransien
tForHint' with no type
/usr/X11R6.4/include/X11/Xlib.h:2066: ANSI C++ forbids declaration
`XActivateScr
eenSaver' with no type
/usr/X11R6.4/include/X11/Xlib.h:2073: ANSI C++ forbids declaration
`XAddHost' wi
th no type
/usr/X11R6.4/include/X11/Xlib.h:2081: ANSI C++ forbids declaration
`XAddHosts' w
ith no type
/usr/X11R6.4/include/X11/Xlib.h:2088: ANSI C++ forbids declaration
`XAddToExtens
ionList' with no type
/usr/X11R6.4/include/X11/Xlib.h:2095: ANSI C++ forbids declaration
`XAddToSaveSe
t' with no type
/usr/X11R6.4/include/X11/Xlib.h:2149: ANSI C++ forbids declaration
`XAllowEvents
' with no type
/usr/X11R6.4/include/X11/Xlib.h:2155: ANSI C++ forbids declaration
`XAutoRepeatO
ff' with no type
g++: make: *** [formula.lo] Error 1
Anybody tried to get the lyx-devel branch running on NT ?
Has anybody experiences to share ? I am having problems with the autogen.sh script, seems that some things are still missing on my system. When I run autogen.sh I get some messages (file attached), then when I try to run ./configure I see the following: loading cache ./config.cache ./configure: 533: Syntax error: word unexpected (expecting ")") My system is NT-4 SP4 with cygwin-beta 20,mumit khan's gcc-2.95-2, autoconf, automake everything fresh installed from original sources today. checked out the lyx-devel tree today Dec 15th. This looks like an automake problem to me. Thanks for any hints. Roland Building macros. aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_LC_MESSAGES' not found in library Building config header template Building Makefile templates configure.in: 5: required file `src/config.h.in' not found automake: src/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' automake: src/mathed/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' automake: src/insets/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' src/support/Makefile.am:7: USE_LYXSTRING does not appear in AM_CONDITIONAL automake: src/support/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' Building configure autoconf: Undefined macros: configure.in:12:AC_VALIDATE_CACHE_SYSTEM_TYPE configure.in:59:AC_DISABLE_SHARED configure.in:60:AC_LIBTOOL_WIN32_DLL run "./configure ; make" gm4: not found gnum4: not found Building lib/configure Creating POTFILES.in... done
Anybody tried to get the lyx-devel branch running on NT ?
Has anybody experiences to share ? I am having problems with the autogen.sh script, seems that some things are still missing on my system. When I run autogen.sh I get some messages (file attached), then when I try to run ./configure I see the following: loading cache ./config.cache ./configure: 533: Syntax error: word unexpected (expecting ")") My system is NT-4 SP4 with cygwin-beta 20,mumit khan's gcc-2.95-2, autoconf, automake everything fresh installed from original sources today. checked out the lyx-devel tree today Dec 15th. This looks like an automake problem to me. Thanks for any hints. Roland Building macros. aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_PATH_PROG_WITH_TEST' not found in library aclocal: configure.in: 0: macro `AM_LC_MESSAGES' not found in library Building config header template Building Makefile templates configure.in: 5: required file `src/config.h.in' not found automake: src/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' automake: src/mathed/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' automake: src/insets/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' src/support/Makefile.am:7: USE_LYXSTRING does not appear in AM_CONDITIONAL automake: src/support/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' Building configure autoconf: Undefined macros: configure.in:12:AC_VALIDATE_CACHE_SYSTEM_TYPE configure.in:59:AC_DISABLE_SHARED configure.in:60:AC_LIBTOOL_WIN32_DLL run "./configure ; make" gm4: not found gnum4: not found Building lib/configure Creating POTFILES.in... done
Lyx trouble with MikTeX
Dear Developers, I am having some problems getting LyX to work correctly on my NT box. Problem 1 I am using MikTeX the latest stable release (www.miktex.de) but the configuration shell script insists on that latex is unusable. I have started to look into the problem but I couldnt get anywhere in a reasonable time. I then hacked the script to disable the test for latex. Dont know but this is really weired because miktex's latex produces the correct line of output, but grep doesnt get it ... Whats the deal with the configuration shell script ? Is it somehow related to autoconf ? Can it be changed / made be more sofisticated ? Problem 2 yap which is one of the the WindowsNT dvi previewers doesnt understand the -paper us option. Now I know from Stephens website that there is a solution but maybe the dvi viewer command could somehow be configured instead of hardcoded. Dont know whether its possible though. Thanks for any suggestions Roland
Lyx trouble with MikTeX
Dear Developers, I am having some problems getting LyX to work correctly on my NT box. Problem 1 I am using MikTeX the latest stable release (www.miktex.de) but the configuration shell script insists on that latex is unusable. I have started to look into the problem but I couldnt get anywhere in a reasonable time. I then hacked the script to disable the test for latex. Dont know but this is really weired because miktex's latex produces the correct line of output, but grep doesnt get it ... Whats the deal with the configuration shell script ? Is it somehow related to autoconf ? Can it be changed / made be more sofisticated ? Problem 2 yap which is one of the the WindowsNT dvi previewers doesnt understand the -paper us option. Now I know from Stephens website that there is a solution but maybe the dvi viewer command could somehow be configured instead of hardcoded. Dont know whether its possible though. Thanks for any suggestions Roland
