Re: lyx-1.1.4pre2 installation bug report (I think)
"Abdel" == Abdelrazak YOUNEs [EMAIL PROTECTED] writes: Abdel checking for prefix by checking for reLyX... (cached) ./reLyX Do you have '.' in your PATH? This is probably the reason why reLyX is found in the build directory. Besides the fact that having '.' in Abdel yes... This should not be a problem in theory, I think it is a bug in autoconf... Abdel Let's not loose faith. Just by watching how my students are Abdel getting motivated, I'm convinced that it will take off !! I hope you'll be proven right! You said earlier that you had machines not suited for windows 9x/NT. What kind of machines are these? Is LyX performance adequate on these machines? It is important that we get feedback from people using slow machines, since most of the developpers probably do not see some problems. In particular, there are plans to remove the so-called 'fast selection' support, because it complicates the code a lot. Do you use it? Also, is support for black-and-white screens important to you? JMarc Abdel PS: Y'a t'il une version française du site??? Non, malheureusement. Il y a un site sur la traduction en francais de la documentation (un peu au point mort en ce moment...), mais c'est tout.
Re: New doc updates (CVS commit also needed)
"Mike" == [EMAIL PROTECTED] writes: Mike In a landslide 1 to 0 vote, with several thousand abstentions, I Mike have proclaimed myself maintainer of UserGuide, Extended, and Mike Customization. (Since I was _temporary_ maintainer of UserGuide Mike for over a year with no volunteers, I figured "What the heck Mike ...".) Great. Mike In a fit of activity, I've carried out my threat of shrinking Mike Lars' multicol description in Extended. The original chapter is Mike appended here (with cleaned up formatting) and should be Mike committed to the CVS examples directory as soon as possible (I Mike don't think I have access to this). Done. Mike I've also risked the "Wrath of John" and moved the ASCII export Mike section from Extended to Customization. This begs the question: Mike is any method of exporting documented??? It wasn't obvious from Mike any of the tables of contents. Has tth use been described? I doubt that exporting (and importing?) is correctly documented. As a rule of thumb, I would say that most new features are undocumented :( JMarc
Re: lyx-1.1.4pre2 installation bug report (I think)
On 25-Jan-2000 Jean-Marc Lasgouttes wrote: Abdel By the way, I checked already the html export feature... very Abdel nice!!! Especially for maths!! I opened my 200p thesis full of Abdel maths and graphics without any problem... One side-note though, Abdel under KDE when the option 'Display content when resizing' is Abdel on, the lyx window doesn't resize well, tits*, the scroll bar Abdel gets scrambled and acts weirdly. I don't know if this is kwm's Abdel or lyx's fault but I thought I could tell you in case (this is Abdel kde-1.1.2). That is probably LyX fault (or rather xforms fault). I don't really know! A lot of programs have problem with the KDE mode of sending update requests when moving or resizing a window in the full grafic mode. We here had problems with tcl-tk applications regulary so that we have to set that option of and don't display the content of the window. Also Motif application are VERY slow on updating there content when resizing. IMO KDE is sending too many update requests and a lot can not be handled correctly. 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 If your life was a horse, you'd have to shoot it. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Space problem
Hi, yet another hint on the space problem: If I cannot enter another space in my text because the space key seems to be "locked", there is an interesting way to make Lyx accept spaces again: You just have to switch to another program on your desktop and switch back to LyX. IMHO this looks like an X-related problem. Michael -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de == S/MIME Cryptographic Signature
Re: bug report on version 1.1.2
If possible, please compress any files before attaching them to emails. I hope this wouldn't bother anybody. Actually, I have got problem getting this mail because the last part of MIME is truncated. I don't know why. Maybe because it's attached as text and there's some characters which aren't encoded. Anyway, compressing attachment could save a lot of bandwidth for everybody. Thanks for your comprehension. Seak
Re: Space problem
"Michael" == Michael Schmitt [EMAIL PROTECTED] writes: Michael maybe the following two new (!) purify messages give a hint Michael on what goes wrong??? I simply opened a new document and Michael typed in a character (a). It seems that these UMR are in debug messages. I am not really sure, but I think they are a bug in CC stream library. Anyway, they probably do not happen with debugging turned off; do the space problem remain with debugging turned off? JMarc
Re: Compilation problems
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel I can't compile the latest cvs because of the using declaration Dekel in lastfiles.C:85 and table.C:746 (I use an old g++ - ver. Dekel 2.90.29) This can the fixed by moving the using declarations to Dekel the global scope, or stop using 'using' (std::copy etc. are Dekel only used once, so the 'using' declaration is unnecessary) What message are you getting? Does moving the 'using' directive at the beginning of the file (in global scope) help? We need these directives because all STLs (notably older ones) do not declare objects in std::. JMarc
Re: Hebrew patch
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | - Lars see whether the change you did to Buffer::pop_tag some time ago Lars | makes sense. Lars Didn't you alter my change? I just replaced a for(int j = j+1;... with for(int j = 0;... Obviously, I see now that this change was wrong. However, your code was wrong too, since, as Jose pointed out, it seems a global variable is necessary. Unfortunately, I do not have the setting nor the knowledge to hack sgml generation code. Lars | - there are problems with kpsewhich handling and bibtex Lars I have so far been unable to reproduce thos problems. Of course Lars if kpsewhich and latex does not match there will be problems. Lars The problem where keys are not listed are another problem... LyX Lars need to find the bib file to be able display the keys. There can also be problems with older versions of kpathsea where --format does not exist. Here is a typical usage message (from Yann Morere): crabe:/usr/local/teTeX/bin/alpha-osf4.0 kpsetool Usage: kpsexpand: [options] string Valid options are the following: -n progname : pretend to be progname to kpathsea -m mode : set Metafont mode -w : act like kpsewhich -p : act like kpsepath -v : act like kpsexpand This is probably not the problem others have been seeing, since they have AFAIK newer tex versions. What about a test in configure to see whether kpsewhich --format=latex article.cls works? [is that the right syntax?] Lars | - still problems with --with-lyxname Lars Hard ones? Or easy to fix? Not sure. Basically, the lyx binary name is not changed. However, I am not sure automake will be happy if I use $(PACKAGE) all over. I'll have to check, but I do not have much time now). An idea I had for later is to change installation to a versionned directory like $prefix/share/lyx/1.1.4 $prefix/share/lyx/1.1.5 and probably $prefix/share/lyx/site-local However, I am not sure how easy it is with automake. And it forces users to uninstall old versions. JMarc
Re: Compilation problems
On Wed, Jan 26, 2000 at 11:39:53AM +0100, Jean-Marc Lasgouttes wrote: "Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel I can't compile the latest cvs because of the using declaration Dekel in lastfiles.C:85 and table.C:746 (I use an old g++ - ver. Dekel 2.90.29) This can the fixed by moving the using declarations to Dekel the global scope, or stop using 'using' (std::copy etc. are Dekel only used once, so the 'using' declaration is unnecessary) What message are you getting? Does moving the 'using' directive at the beginning of the file (in global scope) help? lastfiles.C: In method void LastFiles::writeFile(const class lyxstring ) lastfiles.C:85: parse error before using' Moving the 'using' to the global scope does solve the problem. We need these directives because all STLs (notably older ones) do not declare objects in std::. What I meant was that instead of using std::copy; using std::ostream_iterator; copy(files.begin(), files.end(), ostream_iteratorstring(ofs, "\n")); you can write std::copy(files.begin(), files.end(), std::ostream_iteratorstring(ofs, "\n"));
Re: Space problem
Jean-Marc Lasgouttes wrote:
Michael Ok, I attached a log. I opened a new file, added one
Michael character (a), viewed dvi, added another char (b) to the text
Michael and selected "update dvi", and so on.
OK, two problems: (1) you should post it to the list, since Lars is
the one who knows about this (and probably the one who broke the code,
in fact :) (2) Lars changed the debug flags behind our backs, so you
should use '-dbg depend,latex' now.
I really hope we'll manage to find this one.
Hi Jean-Marc, hi Lars,
enclosed please find a new log file.
Good luck!
Michael
--
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics secretary: +49 451 500 3721
Medical University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de
==
Setting debug level to latex,depend
Debugging `latex' (LaTeX generation/execution)
Debugging `depend' (Dependency information)
Find a free buffer.
Assigning to buffer 0
makeLaTeXFile...
Validating buffer...
Paragraph: 7ffa60
LyX needs the following commands when LaTeXing:
* Packages:
* Macros:\providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
* Textclass stuff:
* done.
Buffer validation done.
lyx header finished
preamble finished, now the body.
TeXOnePar... 7ffa60
SimpleTeXOnePar... 7ffa60
SimpleTeXOnePar...done 7ffa60
TeXOnePar...done 0
makeLaTeXFile...done
Finished making latex file.
Dependency file does not exist
Run #1
Log file: newfile.log
Log line: This is TeX, Version 3.14159 (C version 6.1) (format=latex 97.7.15) 26 JAN
2000 16:33
Log line: **newfile.tex
Log line: (newfile.tex
Log line: LaTeX2e 1997/06/01
Log line: Babel v3.6h and hyphenation patterns for american, german, loaded.
Log line:
Log line: (/opt/local/teTeX-0.4/texmf/tex/latex/base/article.cls
Log line: Document Class: article 1997/06/16 v1.3v Standard LaTeX document class
Log line: (/opt/local/teTeX-0.4/texmf/tex/latex/base/size10.clo
Log line: File: size10.clo 1997/06/16 v1.3v Standard LaTeX file (size option)
Log line: )
Log line: \c@part=\count79
Log line: \c@section=\count80
Log line: \c@subsection=\count81
Log line: \c@subsubsection=\count82
Log line: \c@paragraph=\count83
Log line: \c@subparagraph=\count84
Log line: \c@figure=\count85
Log line: \c@table=\count86
Log line: \abovecaptionskip=\skip41
Log line: \belowcaptionskip=\skip42
Log line: \bibindent=\dimen102
Log line: ) (/opt/local/teTeX-0.4/texmf/tex/latex/base/fontenc.sty
Log line: Package: fontenc 1997/05/07 v1.9d Standard LaTeX package
Log line: (/opt/local/teTeX-0.4/texmf/tex/latex/base/t1enc.def
Log line: File: t1enc.def 1997/05/07 v1.9d Standard LaTeX file
Log line: LaTeX Font Info:Redeclaring font encoding T1 on input line 81.
Log line: )) (/opt/local/teTeX-0.4/texmf/tex/latex/base/inputenc.sty beta test version
Log line: Package: inputenc 1997/05/10 v0.9z Input encoding file (test version: still
lia
Log line: ble to change)
Log line: (/opt/local/teTeX-0.4/texmf/tex/latex/base/latin1.def
Log line: File: latin1.def 1997/05/10 v0.9z Input encoding file (test version: still
liab
Log line: le to change)
Log line: ))
Log line: No file newfile.aux.
Log line: LaTeX Font Info:Checking defaults for OML/cmm/m/it on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: LaTeX Font Info:Checking defaults for T1/cmr/m/n on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: LaTeX Font Info:Checking defaults for OT1/cmr/m/n on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: LaTeX Font Info:Checking defaults for OMS/cmsy/m/n on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: LaTeX Font Info:Checking defaults for OMX/cmex/m/n on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: LaTeX Font Info:Checking defaults for U/cmr/m/n on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: [1
Log line:
Log line: ] (newfile.aux) )
Log line: Here is how much of TeX's memory you used:
Log line: 268 strings out of 10906
Log line: 2774 string characters out of 72023
Log line: 45371 words of memory out of 262141
Log line: 3206 multiletter control sequences out of 9500
Log line: 4403 words of font info for 15 fonts, out of 15 for 255
Log line: 14 hyphenation exceptions out of 607
Log line: 23i,4n,18p,139b,160s stack positions out of 300i,40n,60p,3000b,4000s
Log line:
Log line: Output written on newfile.dvi (1 page, 220 bytes).
Log line:
Found file: C
Not a file or we are unable to find it.
Found file: format=latex
Not a file or we are unable to find it.
Found
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
Re: lyx-1.1.4pre2 installation bug report (I think)
On Wed, Jan 26, 2000 at 10:10:18AM +0100, Jean-Marc Lasgouttes wrote: Abdel PS: Y'a t'il une version française du site??? Non, malheureusement. Il y a un site sur la traduction en francais de la documentation (un peu au point mort en ce moment...), mais c'est tout. Well, that's pretty lame, even if you're trying to hide it by writing it in french. Could you perhaps convince one of the french translators to write up a quick web page in french? They don't have to write too much, since the docs cover how to actually use LyX and they're (in the process of being) translated already. It would just have to describe the simple aspects of setting up french LyX. (Which means you could probably copy the mexican mirror's spanish page and translate it to french.) -Amir
archive of lyx list
Are ascii format archives (plzzeee not html) of the lyx mailing lists available anywhere? Best regards -- lsm
Re: Space problem
Michael Schmitt [EMAIL PROTECTED] writes: | Hi Jean-Marc, hi Lars, | | enclosed please find a new log file. The first run looks ok. In the second run it is detected that there is no change to the .tex file (nor to any other of the files in the dependency list) so all further latexxing is skiped. You are sure that you don't insert a char and then delete it right away? What about if you export the tex file is the added char present there? Lgb
Re: archive of lyx list
[EMAIL PROTECTED] writes: | Are ascii format archives (plzzeee not html) | of the lyx mailing lists available anywhere? To my knowledge no. (unless they serve as basis for the html pages somewhere.) Lgb
Bigger Combox lists
Why the heights of the Combox lists are so small? For example, in the Citation popup, the list shows only 5 keys at a time, which makes it very difficult to use if you have large bibliography database. This can be fixed by changing line 87 of insets/insetbib.C from bibcombox-add(80, 10, 130, 30, 120); to bibcombox-add(80, 10, 130, 30, 300); (or maybe more than 300) Other instances of the combox list should also be enlarged.
Re: Compilation problems
Dekel Tsur [EMAIL PROTECTED] writes: | What I meant was that instead of |using std::copy; |using std::ostream_iterator; |copy(files.begin(), files.end(), |ostream_iteratorstring(ofs, "\n")); | | you can write |std::copy(files.begin(), files.end(), |std::ostream_iteratorstring(ofs, "\n")); | mmm...I want to do that...but so far I have not dared. Eventually "using" should not be used in headers at all, and as little as possible in filescope. Lgb
How ready are we for 1.1.4?
It seems to me that we have managed to remove the worst bugs and is absolutely no worse off than 1.1.3. I know there are some space issues, and some "update dvi" reports, I do not understand how this happens and have failed at reproducing this... Are the configure problems resolved? If there are no further problems I'd like to release 1.1.4 friday. Lgb
Critical: Space problem
Hi, as you know I have some serious problems with spaces. Today I managed to crash (SIGSEGV) Lyx by adding a simple printf statement in function InitLyxLookup (just did that by accident; don't ask me why). Therefore, I started my favorite program: Purify and it reported a lot of problems when entering just " " after "a" in a new document: Of course, I cannot blame you for problems in some external libraries. But maybe you are willing to quickly browse through the list of warning to make sure that it is a problem of my Sun environment? As I stated before I never had such problems before. Moreover, I do not have any problems with characters other than " ". Michael UMR: Uninitialized memory read This is occurring while in: HandleComposeSequence [KeyBind.c] _XTranslateKeySym [KeyBind.c] XLookupString [KeyBind.c] _MbLookupString [XSunIMIF.c] XmbLookupString [ICWrap.c] int LyXLookupString(_XEvent*,char*,int,unsigned long*) [lyxlookup.C:160] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:178] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:361] C_LyXView_KeyPressMask_raw_callback [LyXView.C:395] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:635] LyX::LyX(int*,char**) [lyx_main.C:129] main [main.C:43] _start [crt1.o] Reading 4 bytes from 0xff164b88 between the heap and the stack. Address 0xff164b88 is 340 bytes past start of global variable "compose_table". This is defined in XSunOMIF.c. UMR: Uninitialized memory read This is occurring while in: HandleComposeSequence [KeyBind.c] _XTranslateKeySym [KeyBind.c] XLookupString [KeyBind.c] _MbLookupString [XSunIMIF.c] XmbLookupString [ICWrap.c] int LyXLookupString(_XEvent*,char*,int,unsigned long*) [lyxlookup.C:160] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:178] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:361] C_LyXView_KeyPressMask_raw_callback [LyXView.C:395] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:635] LyX::LyX(int*,char**) [lyx_main.C:129] main [main.C:43] _start [crt1.o] Reading 4 bytes from 0xff164b88 between the heap and the stack. Address 0xff164b88 is 340 bytes past start of global variable "compose_table". This is defined in XSunOMIF.c. UMR: Uninitialized memory read This is occurring while in: HandleComposeSequence [KeyBind.c] _XTranslateKeySym [KeyBind.c] XLookupString [KeyBind.c] _MbLookupString [XSunIMIF.c] XmbLookupString [ICWrap.c] int LyXLookupString(_XEvent*,char*,int,unsigned long*) [lyxlookup.C:160] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:178] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:361] C_LyXView_KeyPressMask_raw_callback [LyXView.C:395] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:635] LyX::LyX(int*,char**) [lyx_main.C:129] main [main.C:43] _start [crt1.o] Reading 4 bytes from 0xff164b88 between the heap and the stack. Address 0xff164b88 is 340 bytes past start of global variable "compose_table". This is defined in XSunOMIF.c. UMR: Uninitialized memory read This is occurring while in: HandleComposeSequence [KeyBind.c] _XTranslateKeySym [KeyBind.c] XLookupString [KeyBind.c] _MbLookupString [XSunIMIF.c] XmbLookupString [ICWrap.c] int LyXLookupString(_XEvent*,char*,int,unsigned long*) [lyxlookup.C:160] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:178] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:361] C_LyXView_KeyPressMask_raw_callback [LyXView.C:395] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:635] LyX::LyX(int*,char**) [lyx_main.C:129] main [main.C:43] _start [crt1.o] Reading 4 bytes from 0xff164b88 between the heap and the stack. Address 0xff164b88 is 340 bytes past start of global variable "compose_table".
index lost
Hi again folks. I'm back -- at least I think I re-subcribed. My current problem is that I indexed two books and it seemed to work great, but now, after additions to both, the index no longer shows up when I view postscript. There is a \printindex line in both files and the little Idx boxes are there and I can click on those and they contain the right stuff. What am I missing (other than my index)? LyX 1.1.3 and LyX-1.1.4pre2 Garst
Re: Critical: Space problem
Michael Schmitt [EMAIL PROTECTED] writes: | Of course, I cannot blame you for problems in some external libraries. | But maybe you are willing to quickly browse through the list of warning | to make sure that it is a problem of my Sun environment? As I stated | before I never had such problems before. Moreover, I do not have any | problems with characters other than " ". You are sure your X header files and libraires match? I have no clue as to what is going on. | UMR: Uninitialized memory read | This is occurring while in: | HandleComposeSequence [KeyBind.c] | _XTranslateKeySym [KeyBind.c] | XLookupString [KeyBind.c] | _MbLookupString [XSunIMIF.c] | XmbLookupString [ICWrap.c] | int LyXLookupString(_XEvent*,char*,int,unsigned long*) | [lyxlookup.C:160] With a debugger you should be able to find out what is happening here, if LyXLookupString is calling XmbLookupString with wring/faulty args. But it seems strange since [...] | Reading 4 bytes from 0xff164b88 between the heap and the stack. | Address 0xff164b88 is 340 bytes past start of global variable | "compose_table". | This is defined in XSunOMIF.c. | UMR: Uninitialized memory read | This is occurring while in: | HandleComposeSequence [KeyBind.c] | _XTranslateKeySym [KeyBind.c] | XLookupString [KeyBind.c] | do_keyboard[libforms.a] | do_interaction_step [libforms.a] here you get the same thing without going through any LyX code at all. Have you locally changed the compose tables? (some X file, don't ask me where to find it...) Does this happen on all space inserts? Regardless of what char it is after, what paragraph it is in. And you find _none_ of these errors in lyx-1.1.3? Lgb
Re: index lost
"Garst R. Reese" [EMAIL PROTECTED] writes:
| Hi again folks.
| I'm back -- at least I think I re-subcribed.
| My current problem is that I indexed two books and it seemed to work
| great, but now, after additions to both, the index no longer shows up
| when I view postscript.
Do they show up on view dvi? (I suppose not)
Can you see if latex is run more than once (on the status line when
selecting update or view)
| There is a \printindex line in both files and the little Idx boxes are
| there and I can click on those and they contain the right stuff.
| What am I missing (other than my index)?
| LyX 1.1.3 and LyX-1.1.4pre2
If you export to latex is the \index{}'s, \makeindex and \printindex
present?
Lgb
libsigc++ integration and gui-indep in LyX
Roland I've taken this to the list since it saves me writing an almost identical email to explain to everyone else what's currently happening. I hope you don't mind. Karl, thanks for your advice. There are a couple of lines relevent for you below -- see discussion about sigc.m4. I thought you might also like to know how my plans are evolving. Everyone, this has grown very long but you should be used to that from me by now. It should contain just about every tiny bit of detail so there should be no need to ask questions as they've already been answered ;-) On Tue, 25 Jan 2000, Dr. Ing. Roland Krause wrote: Allan, thanks for your reply. Yesterday I took some time to look closer into libsigc++ and I must say, that it is pretty good. It is really easy to use and I do not even think that it is to large to incorporate. If it really hold what it promises then this is definitely the right tool for the job. I noticed you filed a report to the libsigc++ list. 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. Allan Rae wrote: I'll also setup an abstract base class for the Popups to inherit from. That should help insure that they all look roughly the same and may provide other advantages later on. Have you already done that? I think I saw something like popup.[Ch]? Hmm maybe that was something else. 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). 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? I'm planning on reworking the sigc++/configure.in and creating a sigc.m4 like the gettext.m4 which provides an AM_WITH_SIGC. This is mainly to work around a couple of tricky "chicken-and-egg" problems and to help reduce the size of our dist. Things like duplicated compiler tests and two copies of libtool etc. I've started work on incorporating libsigc++ but I won't be merging into the main trunk before 1.2.0 -- unless 1.2.0 is considerably further away than I think it is. Is there a 1.1.5 before 1.2.0 - if so why not introducing it there. I dont think it will really break things. 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. 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. The simple trick I employed for gui-indep popups was to say that as far as the kernel is concerned we just need to tell a popup to show itself and to tell those popups that are interested when the buffer has changed. So the signals generally don't carry any information. The second thing is that any popup must be able to do 3 things: show itself, hide itself and update itself. Alright - so these are virtual functions of the base class popup. Yes. These 3 are made targets of signals. A popup specific signal for showing the popup and whichever of the two hide or update signals in Popups that is appropriate. 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. That is - the popup knows where to get the necessary information to update fields, buttons etc. I understand. With the signal/slot mechanism it could have been sent this information but pulling is safer I guess. It's also a question of just how extravegant we are willing to allow our signals/slots to get -- how many parameters we're willing to pass. Also if we only push info down the wire we have to push different info to each popup separately we lose the extremely simple interface of calling one Signal0void updateAllBufferDependent which will call all the _visible_ popups. If we tried to support push to popups we would have to
Re: libsigc++ integration and gui-indep in LyX
Allan Rae [EMAIL PROTECTED] writes: [I dropped the sigc++ list] | 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. Agree. So you are not letting the included sigc++ use its own ./configure? Ok that seems like the best way. Some work needed to the the correct autoconf macros in place then. | 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). Even I managed to checkout the rae branch now. :-) Feel free to commit at any time. | I've started work on incorporating libsigc++ but I won't be merging into | the main trunk before 1.2.0 -- unless 1.2.0 is considerably further away | than I think it is. | | Is there a 1.1.5 before 1.2.0 - if so why not introducing it there. I | dont think it will really break things. I at least expect several versions before 1.2.0. | 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. There are also some other very important things that is closely releated to gui-indep that needs to get done before the ball can begin to roll: the lyx painter, new menucode, new toolbar code. Also the gui initialization needs to get cleaned up. | 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. One other approach is to just not show the popups that has not been implemented yet for the given tk. As as been shown earlier having two toolkits running at the same time is not always possible, and on some systems impossible. (MFC port) | That is - the popup knows where to get the necessary information to | update fields, buttons etc. I understand. With the signal/slot | mechanism it could have been sent this information but pulling is | safer I guess. | | It's also a question of just how extravegant we are willing to allow our | signals/slots to get -- how many parameters we're willing to pass. There is the possiblity of passing objects. | Also if we only push info down the wire we have to push different info to | each popup separately we lose the extremely simple interface of calling | one Signal0void updateAllBufferDependent which will call all the | _visible_ popups. True. | 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 world via | the LyXServer. It is possible that when setting paramters we will do that using lyxfunc too. | I'll probably commit the new stuff over the weekend and then you'll be | able to see the new code. | and forget the whole gtk--sig thing. Good! | Gosh! You wrote PopupBase and called it Popup!! I have thought a bit about this, and perhaps we should switch to the more generally accepted term: "Dialog". Popups are really something else... | Yes, you get the idea! | Although I'm thinking about adding another member and also something very | naughty: a data member, Hey! forget that. | I'm seriously considering suspending my enrolment for 6 months. I'm | working part-time and haven't really done anything constructive | thesis-wise (or otherwise) for at least the last 6 months. The last | subtopic of my thesis crashed and burned so I've lost a lot of interest in | working on it. Besides it seems half the world is waiting for me to get | this gui-indep stuff back on the rails. May as well work on something | that brings some joy and satisfaction and then reassess my thesis in a few | months. Hmmm a fulltime LyX developer would be nice :-) I have been planning to begin the gui-indep work for some time, but so far there have been other task that has been crying to get done. As I see it have no finished a lot of the cleanup that was needed, and we can begin to focues (slowly) on different matters. So my simplistic plan is now: - release 1.1.4 - include the hebrew patch. - remove some code cruft - new prerelease - release 1.1.5 - work on the painter (get asger to tell be what the
Re: ARRae, gui - indep
On Wed, 26 Jan 2000, Dr. Ing. Roland Krause wrote: [...] See my other email "libsigc++ integration..." for details. 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? Communicator was a large bucket into which I poured every bit of code that was common to different gui-indep implementations (or would have been anyway). It went hand in glove with signals/slots. The new plan is to instead turn those Communicator.method()s into LyXFuncs so they can accessed by everyone using a std::string of parameters. 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 ??? You don't. You can use the patch I posted last week to get the old lyx branch up and running but even that patch is now effectively out of date. Or you wait a couple of days and get my branch from cvs. Lets get this baby off the ground. Already rolling and ready for take-off. Allan. (ARRae)
Re: libsigc++ integration and gui-indep in LyX
On 27 Jan 2000, Lars Gullik Bjønnes wrote: Allan Rae [EMAIL PROTECTED] writes: [I dropped the sigc++ list] It was just Karl's private mail address not the list. So you are not letting the included sigc++ use its own ./configure? My first draft does but its a pain -- 12 hours yesterday but I got it working. Ok that seems like the best way. Some work needed to the the correct autoconf macros in place then. I took a look at gettext.m4 and the intl/Makefile and saw how we get around not building internal stuff. I had started writing a LYX_WITH_SIGC that was very rapidly growing. The problems mostly stem from the need to either run sigc++/configure _before_ running the testing of with-included-sigc in configure so that a sigc-config script is created -- this script is used in Karl's supplied sigc++.m4 for testing library versions etc. It's a real chicken-and-egg thing and I haven't tried it yet but we might get away with an AC_SUBDIRS(sigc++) just before the LYX_WITH_SIGC test. It'd also need a few other mods to sigc++/configure.in to setup for not building the library if we're going to use an externally supplied one. This was going to be my second stage of integration but I ran out of blinks last night. There are also some other very important things that is closely releated to gui-indep that needs to get done before the ball can begin to roll: the lyx painter, new menucode, new toolbar code. Also the gui initialization needs to get cleaned up. I was aiming for gui-init + dialogs. The painter, toolbar etc are independent of the dialogs so we can get people working on the dialogs and then branch out from there. As you know from previous discussions I see toolbars as just another form of dialog (stackable, embeddable ones perhaps) so they will eventually be added to the Popups lineup (or should that be Dialogs). | 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. One other approach is to just not show the popups that has not been implemented yet for the given tk. We can cover that on a tk by tk basis. If we can get a workable version why not? | It's also a question of just how extravegant we are willing to allow our | signals/slots to get -- how many parameters we're willing to pass. There is the possiblity of passing objects. Exactly. BufferParams and PrinterParams spring to mind although I'm thinking we should try to just stick to a std::string parameter list. | 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 world via | the LyXServer. It is possible that when setting paramters we will do that using lyxfunc too. More than just possible -- preferably mandatory. | Yes, you get the idea! | Although I'm thinking about adding another member and also something very | naughty: a data member, Hey! forget that. Ouch! Yes Boss! ;-) Hmmm a fulltime LyX developer would be nice :-) Well at least 3 or 4 full days a week. I have been planning to begin the gui-indep work for some time, but so far there have been other task that has been crying to get done. As I see it [I] have no[w] finished a lot of the cleanup that was needed, and we can begin to focues (slowly) on different matters. So my simplistic plan is now: [snipped] SO you want gui-indep started before 1.2.0 then. Okay. I was thinking we'd solidify what we've got and call that 1.2.0 then get the gui-indep foundations built (at least for dialogs) and solidify them, then release 1.3.0 and so on. Hmm I seem to one task I really would have liked to have done: - get rid of current_view. (I think I will work on this too before 1.1.5) Ahh... I remember back in the old days Lars used to load up his truck (Emacs) and head out into the wild blue yonder (lyx repository) and go shoot anything that moved (current_view etc.). Ahh yeahh bring on the old times! ;-) Allan. (ARRae)
Re: libsigc++ integration and gui-indep in LyX
I forgot to mention libsigc++ will drastically affect which compilers will be able to compile LyX. It looks like gcc-2.7.2 will never work and gcc-2.8.x is only just capable perhaps-maybe (sorry JMarc looks like you'll have some extra work). Libsigc++ is developed with egcs-1.1. It hasn't been tested with SUNs 5.0 compilers so that'll be an interesting challenge for Michael -- it should work out of the box (just like LyX ;-) since SUNs compiler supports all the right features. There's a list of tested/supported compilers in the libsigc++ docs. I can forward this to anyone who's too lazy to get a copy of libsigc++ for themselves. Allan. (ARRae)
Re: lyx-1.1.4pre2 installation bug report (I think)
> "Abdel" == Abdelrazak YOUNEs <[EMAIL PROTECTED]> writes: Abdel> checking for prefix by checking for reLyX... (cached) ./reLyX >> Do you have '.' in your PATH? This is probably the reason why >> reLyX is found in the build directory. Besides the fact that having >> '.' in Abdel> yes... This should not be a problem in theory, I think it is a bug in autoconf... Abdel> Let's not loose faith. Just by watching how my students are Abdel> getting motivated, I'm convinced that it will take off !! I hope you'll be proven right! You said earlier that you had machines not suited for windows 9x/NT. What kind of machines are these? Is LyX performance adequate on these machines? It is important that we get feedback from people using slow machines, since most of the developpers probably do not see some problems. In particular, there are plans to remove the so-called 'fast selection' support, because it complicates the code a lot. Do you use it? Also, is support for black-and-white screens important to you? JMarc Abdel> PS: Y'a t'il une version française du site??? Non, malheureusement. Il y a un site sur la traduction en francais de la documentation (un peu au point mort en ce moment...), mais c'est tout.
Re: New doc updates (CVS commit also needed)
> "Mike" == <[EMAIL PROTECTED]> writes: Mike> In a landslide 1 to 0 vote, with several thousand abstentions, I Mike> have proclaimed myself maintainer of UserGuide, Extended, and Mike> Customization. (Since I was _temporary_ maintainer of UserGuide Mike> for over a year with no volunteers, I figured "What the heck Mike> ...".) Great. Mike> In a fit of activity, I've carried out my threat of shrinking Mike> Lars' multicol description in Extended. The original chapter is Mike> appended here (with cleaned up formatting) and should be Mike> committed to the CVS examples directory as soon as possible (I Mike> don't think I have access to this). Done. Mike> I've also risked the "Wrath of John" and moved the ASCII export Mike> section from Extended to Customization. This begs the question: Mike> is any method of exporting documented??? It wasn't obvious from Mike> any of the tables of contents. Has tth use been described? I doubt that exporting (and importing?) is correctly documented. As a rule of thumb, I would say that most new features are undocumented :( JMarc
Re: lyx-1.1.4pre2 installation bug report (I think)
On 25-Jan-2000 Jean-Marc Lasgouttes wrote: > Abdel> By the way, I checked already the html export feature... very > Abdel> nice!!! Especially for maths!! I opened my 200p thesis full of > Abdel> maths and graphics without any problem... One side-note though, > Abdel> under KDE when the option 'Display content when resizing' is > Abdel> on, the lyx window doesn't resize well, tits*, the scroll bar > Abdel> gets scrambled and acts weirdly. I don't know if this is kwm's > Abdel> or lyx's fault but I thought I could tell you in case (this is > Abdel> kde-1.1.2). > > That is probably LyX fault (or rather xforms fault). > I don't really know! A lot of programs have problem with the KDE mode of sending update requests when moving or resizing a window in the full grafic mode. We here had problems with tcl-tk applications regulary so that we have to set that option of and don't display the content of the window. Also Motif application are VERY slow on updating there content when resizing. IMO KDE is sending too many update requests and a lot can not be handled correctly. 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 If your life was a horse, you'd have to shoot it. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Space problem
Hi, yet another hint on the space problem: If I cannot enter another space in my text because the space key seems to be "locked", there is an interesting way to make Lyx accept spaces again: You just have to switch to another program on your desktop and switch back to LyX. IMHO this looks like an X-related problem. Michael -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de == S/MIME Cryptographic Signature
Re: bug report on version 1.1.2
If possible, please compress any files before attaching them to emails. I hope this wouldn't bother anybody. Actually, I have got problem getting this mail because the last part of MIME is truncated. I don't know why. Maybe because it's attached as text and there's some characters which aren't encoded. Anyway, compressing attachment could save a lot of bandwidth for everybody. Thanks for your comprehension. Seak
Re: Space problem
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> maybe the following two new (!) purify messages give a hint Michael> on what goes wrong??? I simply opened a new document and Michael> typed in a character (a). It seems that these UMR are in debug messages. I am not really sure, but I think they are a bug in CC stream library. Anyway, they probably do not happen with debugging turned off; do the space problem remain with debugging turned off? JMarc
Re: Compilation problems
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> I can't compile the latest cvs because of the using declaration Dekel> in lastfiles.C:85 and table.C:746 (I use an old g++ - ver. Dekel> 2.90.29) This can the fixed by moving the using declarations to Dekel> the global scope, or stop using 'using' (std::copy etc. are Dekel> only used once, so the 'using' declaration is unnecessary) What message are you getting? Does moving the 'using' directive at the beginning of the file (in global scope) help? We need these directives because all STLs (notably older ones) do not declare objects in std::. JMarc
Re: Hebrew patch
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | - Lars> see whether the change you did to Buffer::pop_tag some time ago Lars> | makes sense. Lars> Didn't you alter my change? I just replaced a for(int j = j+1;... with for(int j = 0;... Obviously, I see now that this change was wrong. However, your code was wrong too, since, as Jose pointed out, it seems a global variable is necessary. Unfortunately, I do not have the setting nor the knowledge to hack sgml generation code. Lars> | - there are problems with kpsewhich handling and bibtex Lars> I have so far been unable to reproduce thos problems. Of course Lars> if kpsewhich and latex does not match there will be problems. Lars> The problem where keys are not listed are another problem... LyX Lars> need to find the bib file to be able display the keys. There can also be problems with older versions of kpathsea where --format does not exist. Here is a typical usage message (from Yann Morere): crabe:/usr/local/teTeX/bin/alpha-osf4.0> kpsetool Usage: kpsexpand: [options] string Valid options are the following: -n progname : pretend to be progname to kpathsea -m mode : set Metafont mode -w : act like kpsewhich -p : act like kpsepath -v : act like kpsexpand This is probably not the problem others have been seeing, since they have AFAIK newer tex versions. What about a test in configure to see whether kpsewhich --format=latex article.cls works? [is that the right syntax?] Lars> | - still problems with --with-lyxname Lars> Hard ones? Or easy to fix? Not sure. Basically, the lyx binary name is not changed. However, I am not sure automake will be happy if I use $(PACKAGE) all over. I'll have to check, but I do not have much time now). An idea I had for later is to change installation to a versionned directory like $prefix/share/lyx/1.1.4 $prefix/share/lyx/1.1.5 and probably $prefix/share/lyx/site-local However, I am not sure how easy it is with automake. And it forces users to uninstall old versions. JMarc
Re: Compilation problems
On Wed, Jan 26, 2000 at 11:39:53AM +0100, Jean-Marc Lasgouttes wrote: > > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: > > Dekel> I can't compile the latest cvs because of the using declaration > Dekel> in lastfiles.C:85 and table.C:746 (I use an old g++ - ver. > Dekel> 2.90.29) This can the fixed by moving the using declarations to > Dekel> the global scope, or stop using 'using' (std::copy etc. are > Dekel> only used once, so the 'using' declaration is unnecessary) > > What message are you getting? Does moving the 'using' directive at the > beginning of the file (in global scope) help? > lastfiles.C: In method void LastFiles::writeFile(const class lyxstring &) lastfiles.C:85: parse error before using' Moving the 'using' to the global scope does solve the problem. > We need these directives because all STLs (notably older ones) do not > declare objects in std::. > What I meant was that instead of using std::copy; using std::ostream_iterator; copy(files.begin(), files.end(), ostream_iterator(ofs, "\n")); you can write std::copy(files.begin(), files.end(), std::ostream_iterator(ofs, "\n"));
Re: Space problem
Jean-Marc Lasgouttes wrote:
> Michael> Ok, I attached a log. I opened a new file, added one
> Michael> character (a), viewed dvi, added another char (b) to the text
> Michael> and selected "update dvi", and so on.
>
> OK, two problems: (1) you should post it to the list, since Lars is
> the one who knows about this (and probably the one who broke the code,
> in fact :) (2) Lars changed the debug flags behind our backs, so you
> should use '-dbg depend,latex' now.
>
> I really hope we'll manage to find this one.
Hi Jean-Marc, hi Lars,
enclosed please find a new log file.
Good luck!
Michael
--
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics secretary: +49 451 500 3721
Medical University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de
==
Setting debug level to latex,depend
Debugging `latex' (LaTeX generation/execution)
Debugging `depend' (Dependency information)
Find a free buffer.
Assigning to buffer 0
makeLaTeXFile...
Validating buffer...
Paragraph: 7ffa60
LyX needs the following commands when LaTeXing:
* Packages:
* Macros:\providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
* Textclass stuff:
* done.
Buffer validation done.
lyx header finished
preamble finished, now the body.
TeXOnePar... 7ffa60
SimpleTeXOnePar... 7ffa60
SimpleTeXOnePar...done 7ffa60
TeXOnePar...done 0
makeLaTeXFile...done
Finished making latex file.
Dependency file does not exist
Run #1
Log file: newfile.log
Log line: This is TeX, Version 3.14159 (C version 6.1) (format=latex 97.7.15) 26 JAN
2000 16:33
Log line: **newfile.tex
Log line: (newfile.tex
Log line: LaTeX2e <1997/06/01>
Log line: Babel and hyphenation patterns for american, german, loaded.
Log line:
Log line: (/opt/local/teTeX-0.4/texmf/tex/latex/base/article.cls
Log line: Document Class: article 1997/06/16 v1.3v Standard LaTeX document class
Log line: (/opt/local/teTeX-0.4/texmf/tex/latex/base/size10.clo
Log line: File: size10.clo 1997/06/16 v1.3v Standard LaTeX file (size option)
Log line: )
Log line: \c@part=\count79
Log line: \c@section=\count80
Log line: \c@subsection=\count81
Log line: \c@subsubsection=\count82
Log line: \c@paragraph=\count83
Log line: \c@subparagraph=\count84
Log line: \c@figure=\count85
Log line: \c@table=\count86
Log line: \abovecaptionskip=\skip41
Log line: \belowcaptionskip=\skip42
Log line: \bibindent=\dimen102
Log line: ) (/opt/local/teTeX-0.4/texmf/tex/latex/base/fontenc.sty
Log line: Package: fontenc 1997/05/07 v1.9d Standard LaTeX package
Log line: (/opt/local/teTeX-0.4/texmf/tex/latex/base/t1enc.def
Log line: File: t1enc.def 1997/05/07 v1.9d Standard LaTeX file
Log line: LaTeX Font Info:Redeclaring font encoding T1 on input line 81.
Log line: )) (/opt/local/teTeX-0.4/texmf/tex/latex/base/inputenc.sty beta test version
Log line: Package: inputenc 1997/05/10 v0.9z Input encoding file (test version: still
lia
Log line: ble to change)
Log line: (/opt/local/teTeX-0.4/texmf/tex/latex/base/latin1.def
Log line: File: latin1.def 1997/05/10 v0.9z Input encoding file (test version: still
liab
Log line: le to change)
Log line: ))
Log line: No file newfile.aux.
Log line: LaTeX Font Info:Checking defaults for OML/cmm/m/it on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: LaTeX Font Info:Checking defaults for T1/cmr/m/n on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: LaTeX Font Info:Checking defaults for OT1/cmr/m/n on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: LaTeX Font Info:Checking defaults for OMS/cmsy/m/n on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: LaTeX Font Info:Checking defaults for OMX/cmex/m/n on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: LaTeX Font Info:Checking defaults for U/cmr/m/n on input line 17.
Log line: LaTeX Font Info:... okay on input line 17.
Log line: [1
Log line:
Log line: ] (newfile.aux) )
Log line: Here is how much of TeX's memory you used:
Log line: 268 strings out of 10906
Log line: 2774 string characters out of 72023
Log line: 45371 words of memory out of 262141
Log line: 3206 multiletter control sequences out of 9500
Log line: 4403 words of font info for 15 fonts, out of 15 for 255
Log line: 14 hyphenation exceptions out of 607
Log line: 23i,4n,18p,139b,160s stack positions out of 300i,40n,60p,3000b,4000s
Log line:
Log line: Output written on newfile.dvi (1 page, 220 bytes).
Log line:
Found file: C
Not a file or we are unable to find it.
Found file: format=latex
Not a file or we are unable to find
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
Re: lyx-1.1.4pre2 installation bug report (I think)
On Wed, Jan 26, 2000 at 10:10:18AM +0100, Jean-Marc Lasgouttes wrote: > > Abdel> PS: Y'a t'il une version française du site??? > > Non, malheureusement. Il y a un site sur la traduction en francais de > la documentation (un peu au point mort en ce moment...), mais c'est > tout. Well, that's pretty lame, even if you're trying to hide it by writing it in french. Could you perhaps convince one of the french translators to write up a quick web page in french? They don't have to write too much, since the docs cover how to actually use LyX and they're (in the process of being) translated already. It would just have to describe the simple aspects of setting up french LyX. (Which means you could probably copy the mexican mirror's spanish page and translate it to french.) -Amir
archive of lyx list
Are ascii format archives (plzzeee not html) of the lyx mailing lists available anywhere? Best regards -- lsm
Re: Space problem
Michael Schmitt <[EMAIL PROTECTED]> writes: | Hi Jean-Marc, hi Lars, | | enclosed please find a new log file. The first run looks ok. In the second run it is detected that there is no change to the .tex file (nor to any other of the files in the dependency list) so all further latexxing is skiped. You are sure that you don't insert a char and then delete it right away? What about if you export the tex file is the added char present there? Lgb
Re: archive of lyx list
[EMAIL PROTECTED] writes: | Are ascii format archives (plzzeee not html) | of the lyx mailing lists available anywhere? To my knowledge no. (unless they serve as basis for the html pages somewhere.) Lgb
Bigger Combox lists
Why the heights of the Combox lists are so small? For example, in the Citation popup, the list shows only 5 keys at a time, which makes it very difficult to use if you have large bibliography database. This can be fixed by changing line 87 of insets/insetbib.C from bibcombox->add(80, 10, 130, 30, 120); to bibcombox->add(80, 10, 130, 30, 300); (or maybe more than 300) Other instances of the combox list should also be enlarged.
Re: Compilation problems
Dekel Tsur <[EMAIL PROTECTED]> writes: | What I meant was that instead of |using std::copy; |using std::ostream_iterator; |copy(files.begin(), files.end(), |ostream_iterator(ofs, "\n")); | | you can write |std::copy(files.begin(), files.end(), |std::ostream_iterator(ofs, "\n")); | mmm...I want to do that...but so far I have not dared. Eventually "using" should not be used in headers at all, and as little as possible in filescope. Lgb
How ready are we for 1.1.4?
It seems to me that we have managed to remove the worst bugs and is absolutely no worse off than 1.1.3. I know there are some space issues, and some "update dvi" reports, I do not understand how this happens and have failed at reproducing this... Are the configure problems resolved? If there are no further problems I'd like to release 1.1.4 friday. Lgb
Critical: Space problem
Hi, as you know I have some serious problems with spaces. Today I managed to crash (SIGSEGV) Lyx by adding a simple printf statement in function InitLyxLookup (just did that by accident; don't ask me why). Therefore, I started my favorite program: Purify and it reported a lot of problems when entering just " " after "a" in a new document: Of course, I cannot blame you for problems in some external libraries. But maybe you are willing to quickly browse through the list of warning to make sure that it is a problem of my Sun environment? As I stated before I never had such problems before. Moreover, I do not have any problems with characters other than " ". Michael UMR: Uninitialized memory read This is occurring while in: HandleComposeSequence [KeyBind.c] _XTranslateKeySym [KeyBind.c] XLookupString [KeyBind.c] _MbLookupString [XSunIMIF.c] XmbLookupString [ICWrap.c] int LyXLookupString(_XEvent*,char*,int,unsigned long*) [lyxlookup.C:160] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:178] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:361] C_LyXView_KeyPressMask_raw_callback [LyXView.C:395] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:635] LyX::LyX(int*,char**) [lyx_main.C:129] main [main.C:43] _start [crt1.o] Reading 4 bytes from 0xff164b88 between the heap and the stack. Address 0xff164b88 is 340 bytes past start of global variable "compose_table". This is defined in XSunOMIF.c. UMR: Uninitialized memory read This is occurring while in: HandleComposeSequence [KeyBind.c] _XTranslateKeySym [KeyBind.c] XLookupString [KeyBind.c] _MbLookupString [XSunIMIF.c] XmbLookupString [ICWrap.c] int LyXLookupString(_XEvent*,char*,int,unsigned long*) [lyxlookup.C:160] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:178] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:361] C_LyXView_KeyPressMask_raw_callback [LyXView.C:395] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:635] LyX::LyX(int*,char**) [lyx_main.C:129] main [main.C:43] _start [crt1.o] Reading 4 bytes from 0xff164b88 between the heap and the stack. Address 0xff164b88 is 340 bytes past start of global variable "compose_table". This is defined in XSunOMIF.c. UMR: Uninitialized memory read This is occurring while in: HandleComposeSequence [KeyBind.c] _XTranslateKeySym [KeyBind.c] XLookupString [KeyBind.c] _MbLookupString [XSunIMIF.c] XmbLookupString [ICWrap.c] int LyXLookupString(_XEvent*,char*,int,unsigned long*) [lyxlookup.C:160] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:178] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:361] C_LyXView_KeyPressMask_raw_callback [LyXView.C:395] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:635] LyX::LyX(int*,char**) [lyx_main.C:129] main [main.C:43] _start [crt1.o] Reading 4 bytes from 0xff164b88 between the heap and the stack. Address 0xff164b88 is 340 bytes past start of global variable "compose_table". This is defined in XSunOMIF.c. UMR: Uninitialized memory read This is occurring while in: HandleComposeSequence [KeyBind.c] _XTranslateKeySym [KeyBind.c] XLookupString [KeyBind.c] _MbLookupString [XSunIMIF.c] XmbLookupString [ICWrap.c] int LyXLookupString(_XEvent*,char*,int,unsigned long*) [lyxlookup.C:160] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:178] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:361] C_LyXView_KeyPressMask_raw_callback [LyXView.C:395] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:635] LyX::LyX(int*,char**) [lyx_main.C:129] main [main.C:43] _start [crt1.o] Reading 4 bytes from 0xff164b88 between the heap and the stack. Address 0xff164b88 is 340 bytes past start of global variable "compose_table".
index lost
Hi again folks. I'm back -- at least I think I re-subcribed. My current problem is that I indexed two books and it seemed to work great, but now, after additions to both, the index no longer shows up when I view postscript. There is a \printindex line in both files and the little Idx boxes are there and I can click on those and they contain the right stuff. What am I missing (other than my index)? LyX 1.1.3 and LyX-1.1.4pre2 Garst
Re: Critical: Space problem
Michael Schmitt <[EMAIL PROTECTED]> writes: | Of course, I cannot blame you for problems in some external libraries. | But maybe you are willing to quickly browse through the list of warning | to make sure that it is a problem of my Sun environment? As I stated | before I never had such problems before. Moreover, I do not have any | problems with characters other than " ". You are sure your X header files and libraires match? I have no clue as to what is going on. | UMR: Uninitialized memory read | This is occurring while in: | HandleComposeSequence [KeyBind.c] | _XTranslateKeySym [KeyBind.c] | XLookupString [KeyBind.c] | _MbLookupString [XSunIMIF.c] | XmbLookupString [ICWrap.c] | int LyXLookupString(_XEvent*,char*,int,unsigned long*) | [lyxlookup.C:160] With a debugger you should be able to find out what is happening here, if LyXLookupString is calling XmbLookupString with wring/faulty args. But it seems strange since [...] | Reading 4 bytes from 0xff164b88 between the heap and the stack. | Address 0xff164b88 is 340 bytes past start of global variable | "compose_table". | This is defined in XSunOMIF.c. | UMR: Uninitialized memory read | This is occurring while in: | HandleComposeSequence [KeyBind.c] | _XTranslateKeySym [KeyBind.c] | XLookupString [KeyBind.c] | do_keyboard[libforms.a] | do_interaction_step [libforms.a] here you get the same thing without going through any LyX code at all. Have you locally changed the compose tables? (some X file, don't ask me where to find it...) Does this happen on all space inserts? Regardless of what char it is after, what paragraph it is in. And you find _none_ of these errors in lyx-1.1.3? Lgb
Re: index lost
"Garst R. Reese" <[EMAIL PROTECTED]> writes:
| Hi again folks.
| I'm back -- at least I think I re-subcribed.
| My current problem is that I indexed two books and it seemed to work
| great, but now, after additions to both, the index no longer shows up
| when I view postscript.
Do they show up on view dvi? (I suppose not)
Can you see if latex is run more than once (on the status line when
selecting update or view)
| There is a \printindex line in both files and the little Idx boxes are
| there and I can click on those and they contain the right stuff.
| What am I missing (other than my index)?
| LyX 1.1.3 and LyX-1.1.4pre2
If you export to latex is the \index{}'s, \makeindex and \printindex
present?
Lgb
libsigc++ integration and gui-indep in LyX
Roland I've taken this to the list since it saves me writing an almost identical email to explain to everyone else what's currently happening. I hope you don't mind. Karl, thanks for your advice. There are a couple of lines relevent for you below -- see discussion about sigc.m4. I thought you might also like to know how my plans are evolving. Everyone, this has grown very long but you should be used to that from me by now. It should contain just about every tiny bit of detail so there should be no need to ask questions as they've already been answered ;-) On Tue, 25 Jan 2000, Dr. Ing. Roland Krause wrote: > Allan, thanks for your reply. > Yesterday I took some time to look closer into libsigc++ and I must > say, that it is pretty good. It is really easy to use and I do not > even think that it is to large to incorporate. If it really hold what > it promises then this is definitely the right tool for the job. I noticed you filed a report to the libsigc++ list. 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. > Allan Rae wrote: > > > I'll also setup an abstract base class for the Popups to inherit from. > > That should help insure that they all look roughly the same and may > > provide other advantages later on. > > Have you already done that? I think I saw something like popup.[Ch]? > Hmm maybe that was something else. 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). 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? I'm planning on reworking the sigc++/configure.in and creating a sigc.m4 like the gettext.m4 which provides an AM_WITH_SIGC. This is mainly to work around a couple of tricky "chicken-and-egg" problems and to help reduce the size of our dist. Things like duplicated compiler tests and two copies of libtool etc. > > I've started work on incorporating libsigc++ but I won't be merging into > > the main trunk before 1.2.0 -- unless 1.2.0 is considerably further away > > than I think it is. > > Is there a 1.1.5 before 1.2.0 - if so why not introducing it there. I > dont think it will really break things. 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. 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. > > The simple trick I employed for gui-indep popups was to say that as > > far as the kernel is concerned we just need to tell a popup to show > > itself and to tell those popups that are interested when the buffer > > has changed. So the signals generally don't carry any information. > > The second thing is that any popup must be able to do 3 things: > > show itself, hide itself and update itself. > > Alright - so these are virtual functions of the base class popup. Yes. > > These 3 are made targets of signals. A popup specific signal for showing > > the popup and whichever of the two hide or update signals in Popups that > > is appropriate. > > > > 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. > > That is - the popup knows where to get the necessary information to > update fields, buttons etc. I understand. With the signal/slot > mechanism it could have been sent this information but pulling is > safer I guess. It's also a question of just how extravegant we are willing to allow our signals/slots to get -- how many parameters we're willing to pass. Also if we only push info down the wire we have to push different info to each popup separately we lose the extremely simple interface of calling one Signal0 updateAllBufferDependent which will call all the _visible_ popups. If
Re: libsigc++ integration and gui-indep in LyX
Allan Rae <[EMAIL PROTECTED]> writes: [I dropped the sigc++ list] | 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. Agree. So you are not letting the included sigc++ use its own ./configure? Ok that seems like the best way. Some work needed to the the correct autoconf macros in place then. | 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). Even I managed to checkout the rae branch now. :-) Feel free to commit at any time. | > > I've started work on incorporating libsigc++ but I won't be merging into | > > the main trunk before 1.2.0 -- unless 1.2.0 is considerably further away | > > than I think it is. | > | > Is there a 1.1.5 before 1.2.0 - if so why not introducing it there. I | > dont think it will really break things. I at least expect several versions before 1.2.0. | 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. There are also some other very important things that is closely releated to gui-indep that needs to get done before the ball can begin to roll: the lyx painter, new menucode, new toolbar code. Also the gui initialization needs to get cleaned up. | 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. One other approach is to just not show the popups that has not been implemented yet for the given tk. As as been shown earlier having two toolkits running at the same time is not always possible, and on some systems impossible. (MFC port) | > That is - the popup knows where to get the necessary information to | > update fields, buttons etc. I understand. With the signal/slot | > mechanism it could have been sent this information but pulling is | > safer I guess. | | It's also a question of just how extravegant we are willing to allow our | signals/slots to get -- how many parameters we're willing to pass. There is the possiblity of passing objects. | Also if we only push info down the wire we have to push different info to | each popup separately we lose the extremely simple interface of calling | one Signal0 updateAllBufferDependent which will call all the | _visible_ popups. True. | 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 world via | the LyXServer. It is possible that when setting paramters we will do that using lyxfunc too. | I'll probably commit the new stuff over the weekend and then you'll be | able to see the new code. | and forget the whole gtk--sig thing. Good! | Gosh! You wrote PopupBase and called it Popup!! I have thought a bit about this, and perhaps we should switch to the more generally accepted term: "Dialog". Popups are really something else... | Yes, you get the idea! | Although I'm thinking about adding another member and also something very | naughty: a data member, Hey! forget that. | I'm seriously considering suspending my enrolment for 6 months. I'm | working part-time and haven't really done anything constructive | thesis-wise (or otherwise) for at least the last 6 months. The last | subtopic of my thesis crashed and burned so I've lost a lot of interest in | working on it. Besides it seems half the world is waiting for me to get | this gui-indep stuff back on the rails. May as well work on something | that brings some joy and satisfaction and then reassess my thesis in a few | months. Hmmm a fulltime LyX developer would be nice :-) I have been planning to begin the gui-indep work for some time, but so far there have been other task that has been crying to get done. As I see it have no finished a lot of the cleanup that was needed, and we can begin to focues (slowly) on different matters. So my simplistic plan is now: - release 1.1.4 - include the hebrew patch. - remove some code cruft - new prerelease - release 1.1.5 - work on the painter (get asger to tell be
Re: ARRae, gui - indep
On Wed, 26 Jan 2000, Dr. Ing. Roland Krause wrote: [...] See my other email "libsigc++ integration..." for details. > 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? Communicator was a large bucket into which I poured every bit of code that was common to different gui-indep implementations (or would have been anyway). It went hand in glove with signals/slots. The new plan is to instead turn those Communicator.method()s into LyXFuncs so they can accessed by everyone using a std::string of parameters. > 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 > ??? You don't. You can use the patch I posted last week to get the old lyx branch up and running but even that patch is now effectively out of date. Or you wait a couple of days and get my branch from cvs. > Lets get this baby off the ground. Already rolling and ready for take-off. Allan. (ARRae)
Re: libsigc++ integration and gui-indep in LyX
On 27 Jan 2000, Lars Gullik Bjønnes wrote: > Allan Rae <[EMAIL PROTECTED]> writes: > > [I dropped the sigc++ list] It was just Karl's private mail address not the list. > So you are not letting the included sigc++ use its own ./configure? My first draft does but its a pain -- 12 hours yesterday but I got it working. > Ok that seems like the best way. Some work needed to the the correct > autoconf macros in place then. I took a look at gettext.m4 and the intl/Makefile and saw how we get around not building internal stuff. I had started writing a LYX_WITH_SIGC that was very rapidly growing. The problems mostly stem from the need to either run sigc++/configure _before_ running the testing of with-included-sigc in configure so that a sigc-config script is created -- this script is used in Karl's supplied sigc++.m4 for testing library versions etc. It's a real chicken-and-egg thing and I haven't tried it yet but we might get away with an AC_SUBDIRS(sigc++) just before the LYX_WITH_SIGC test. It'd also need a few other mods to sigc++/configure.in to setup for not building the library if we're going to use an externally supplied one. This was going to be my second stage of integration but I ran out of blinks last night. > There are also some other very important things that is closely > releated to gui-indep that needs to get done before the ball can begin > to roll: the lyx painter, new menucode, new toolbar code. > Also the gui initialization needs to get cleaned up. I was aiming for gui-init + dialogs. The painter, toolbar etc are independent of the dialogs so we can get people working on the dialogs and then branch out from there. As you know from previous discussions I see toolbars as just another form of dialog (stackable, embeddable ones perhaps) so they will eventually be added to the Popups lineup (or should that be Dialogs). > | 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. > > One other approach is to just not show the popups that has not been > implemented yet for the given tk. We can cover that on a tk by tk basis. If we can get a workable version why not? > | It's also a question of just how extravegant we are willing to allow our > | signals/slots to get -- how many parameters we're willing to pass. > > There is the possiblity of passing objects. Exactly. BufferParams and PrinterParams spring to mind although I'm thinking we should try to just stick to a std::string parameter list. > | 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 world via > | the LyXServer. > > It is possible that when setting paramters we will do that using > lyxfunc too. More than just possible -- preferably mandatory. > | Yes, you get the idea! > | Although I'm thinking about adding another member and also something very > | naughty: a data member, > > Hey! forget that. Ouch! Yes Boss! ;-) > Hmmm a fulltime LyX developer would be nice :-) Well at least 3 or 4 full days a week. > I have been planning to begin the gui-indep work for some time, but so > far there have been other task that has been crying to get done. As I > see it [I] have no[w] finished a lot of the cleanup that was needed, and > we can begin to focues (slowly) on different matters. > So my simplistic plan is now: [snipped] SO you want gui-indep started before 1.2.0 then. Okay. I was thinking we'd solidify what we've got and call that 1.2.0 then get the gui-indep foundations built (at least for dialogs) and solidify them, then release 1.3.0 and so on. > Hmm I seem to one task I really would have liked to have done: > - get rid of current_view. > (I think I will work on this too before 1.1.5) Ahh... I remember back in the old days Lars used to load up his truck (Emacs) and head out into the wild blue yonder (lyx repository) and go shoot anything that moved (current_view etc.). Ahh yeahh bring on the old times! ;-) Allan. (ARRae)
Re: libsigc++ integration and gui-indep in LyX
I forgot to mention libsigc++ will drastically affect which compilers will be able to compile LyX. It looks like gcc-2.7.2 will never work and gcc-2.8.x is only just capable perhaps-maybe (sorry JMarc looks like you'll have some extra work). Libsigc++ is developed with egcs-1.1. It hasn't been tested with SUNs 5.0 compilers so that'll be an interesting challenge for Michael -- it should work out of the box (just like LyX ;-) since SUNs compiler supports all the right features. There's a list of tested/supported compilers in the libsigc++ docs. I can forward this to anyone who's too lazy to get a copy of libsigc++ for themselves. Allan. (ARRae)
