Re: PATCH pspell.m4
Garst R. Reese [EMAIL PROTECTED] writes: | ChangeLog | 2002-05-15 Garst Reese [EMAIL PROTECTED] | * fix cp boo boo | * fix to work with .so as well as .a or both.--- pspell.m4.save Wed May 15 |17:54:20 2002 | +++ pspell.m4 Wed May 15 20:49:46 2002 | @@ -31,12 +31,12 @@ |pspell_lib_found=Setting to $pspell_use_lib | else |pspell_libs=/usr/lib /usr/lib/pspell /usr/local/lib /usr/local/lib/pspell | - AC_FIND_FILE(libpspell.a,$pspell_libs,pspell_use_lib) | + AC_FIND_FILE(libpspell.a libpspell.so,$pspell_libs,pspell_use_lib) |pspell_lib_found=yes | fi | | if test $pspell_use_include = NO || \ | - test $pspell_use_include = NO; then | + test $pspell_use_lib = NO; then |if test $USE_PSPELL = yes; then | USE_PSPELL=not found |fi I do not think that this is the solution that we really want, on my box. libpspell is a libtool library: libpspell.la I do not know how other boxes does this, do they also have a libtool lib? I wonder why pspell.m4 does not use the regular machinery for finding libraries and header files. -- Lgb
Re: PATCH pspell.m4
Garst R. Reese [EMAIL PROTECTED] writes: | Garst R. Reese wrote: | Oops, the ChangeLog was too incomplete | ChangeLog | 2002-05-15 Garst Reese [EMAIL PROTECTED] | * fix pspell.m4 cp boo boo | * fix pspell.m4 to work with .so as well as .a or both. It really should have been: * (pspell.m4): cp boo boo fix to work with .so as well as .a or both. But as I said we should also check for .la, and perhaps change the discovery functions a bit. -- Lgb
Re: Non-float graphics sizing sort of bug
Rod Pinna wrote:
Just opened a file of mine, from 1.1.6fix4, which has a number of
non-floating eps files. The output from latex has these is incorrectly
sized. The graphics are scaled to a percentage of the paper width.
In 1.1.6f4, the file is set to 85% of page. This produces the following
tex
{\centering \resizebox*{0.85\textwidth}{!}{\includegraphics...}
In 1.2.0, the include is set to Width 85 page%, and the tex produced is
\begin{center}\includegraphics[
width=0.85\paperwidth]{filename}\end{center}
Actually, I see, the new version has a text% option, which seems to
match the output of the previous % of page option.
Not sure if I should call it a bug then...possibly the import should
convert the 1.1.6 page width to the 1.2.0 text width.
it's a real bug! And we don't have any vertical length in
the length-choice
Herbert
--
http://www.lyx.org/help/
rc1
I just created the 1.2.x branch, and just put rc1 out. On Rc1 I only want to fix blatant compilation errors or configure install errors, and only if the errors are important enough. The pspell fix does not cut it so far. I am leaving for the weekend + monday later today, so I do not want to release 1.2.0 right now, but rather put down next Wednesday as the release date, unless something unforeseen comes up. -- Lgb
make rpmdist
Is there anything special required to run this? I was trying it for the first time and got soon stuck with make[4]: Entering directory `/usr/src/lyx/lyx-devel/src/frontends/qt2/xforms' make[4]: *** No rule to make target `libqt2xforms.la.c', needed by `distdir'. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
Andre Poenitz [EMAIL PROTECTED] writes: | Is there anything special required to run this? | I was trying it for the first time and got soon stuck with | make[4]: Entering directory `/usr/src/lyx/lyx-devel/src/frontends/qt2/xforms' | make[4]: *** No rule to make target `libqt2xforms.la.c', needed by | `distdir'. Then you have something fishy in your source/build tree or on your box, I use make dist make distdir and make distcheck all the time. Are you trying to compile with qt? a rm -rf qt2 and then recheckout + autogen + configure would probably help. -- Lgb
Re: PATCH pspell.m4
Garst R. Reese [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: I do not think that this is the solution that we really want, on my box. libpspell is a libtool library: libpspell.la I do not know how other boxes does this, do they also have a libtool lib? I wonder why pspell.m4 does not use the regular machinery for finding libraries and header files. | I also have a libpspell.la. I have not a clue what the regular | machinery would be, AC_CHECK_LIB f.ex. | but at least this does not screw up. It would do | just as well to just look for libpspell.la tho. yes. perhaps .la .so .a then... -- Lgb
autogen.sh warnings
After a clean checkout I get Building Makefile templates... . src/frontends/qt2/xforms/Makefile.am:15: invalid unused variable name: `nodist_libqt2xforms_la_SOURCES' src/frontends/qt2/moc/Makefile.am:18: invalid unused variable name: `nodist_libqt2moc_la_SOURCES' src/frontends/qt2/ui/Makefile.am:19: invalid unused variable name: `nodist_libqt2ui_la_SOURCES' src/frontends/qt2/ui/moc/Makefile.am:17: invalid unused variable name: `nodist_libqt2uimoc_la_SOURCES' Is this necessary/intended? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
On Thu, May 16, 2002 at 11:20:59AM +0200, Lars Gullik Bjønnes wrote: Then you have something fishy in your source/build tree or on your box, I use make dist make distdir and make distcheck all the time. 'make dist' already does not work on a clean check out. Are you trying to compile with qt? No. a rm -rf qt2 and then recheckout + autogen + configure would probably help. The directory frontends/qt2/xforms is empty but for a 'Makefile.am' which is not empty: include $(top_srcdir)/config/common.am noinst_LTLIBRARIES = libqt2xforms.la INCLUDES = -I$(top_srcdir)/src/ -I$(top_srcdir)/src/frontends/ \ $(SIGC_CFLAGS) -I$(top_srcdir)/images \ $(FRONTEND_INCLUDES) $(BOOST_INCLUDES) \ -I$(top_srcdir)/src/frontends/controllers if USE_BASIC_IMAGE_LOADER else XFORMSGIMAGE = xformsGImage.C xformsGImage.h endif nodist_libqt2xforms_la_SOURCES = \ bmtable.h \ bmtable.c \ combox.h \ combox.C \ [.] This somehow does not look sound Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: autogen.sh warnings
Andre Poenitz [EMAIL PROTECTED] writes: | After a clean checkout I get I never get that. | Building Makefile templates... | . | src/frontends/qt2/xforms/Makefile.am:15: invalid unused variable name: | `nodist_libqt2xforms_la_SOURCES' | src/frontends/qt2/moc/Makefile.am:18: invalid unused variable name: | `nodist_libqt2moc_la_SOURCES' | src/frontends/qt2/ui/Makefile.am:19: invalid unused variable name: | `nodist_libqt2ui_la_SOURCES' | src/frontends/qt2/ui/moc/Makefile.am:17: invalid unused variable name: | `nodist_libqt2uimoc_la_SOURCES' | Is this necessary/intended? automake version please. I 1.5 without problems. -- Lgb
Re: make rpmdist
Andre Poenitz [EMAIL PROTECTED] writes: | On Thu, May 16, 2002 at 11:20:59AM +0200, Lars Gullik Bjønnes wrote: Then you have something fishy in your source/build tree or on your box, I use make dist make distdir and make distcheck all the time. | 'make dist' already does not work on a clean check out. Are you trying to compile with qt? | No. a rm -rf qt2 and then recheckout + autogen + configure would probably help. | The directory frontends/qt2/xforms is empty but for a 'Makefile.am' which | is not empty: | include $(top_srcdir)/config/common.am | noinst_LTLIBRARIES = libqt2xforms.la | INCLUDES = -I$(top_srcdir)/src/ -I$(top_srcdir)/src/frontends/ \ | $(SIGC_CFLAGS) -I$(top_srcdir)/images \ | $(FRONTEND_INCLUDES) $(BOOST_INCLUDES) \ | -I$(top_srcdir)/src/frontends/controllers | if USE_BASIC_IMAGE_LOADER | else | XFORMSGIMAGE = xformsGImage.C xformsGImage.h | endif | nodist_libqt2xforms_la_SOURCES = \ | bmtable.h \ | bmtable.c \ | combox.h \ | combox.C \ | [.] | This somehow does not look sound To me it looks perfectly sound... -- Lgb
Re: autogen.sh warnings
On Thu, May 16, 2002 at 01:16:49PM +0200, Lars Gullik Bjønnes wrote: automake version please. I 1.5 without problems. 1.4-p5 Should I upgrade? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
On Thu, May 16, 2002 at 01:19:54PM +0200, Lars Gullik Bjønnes wrote: | nodist_libqt2xforms_la_SOURCES = \ | bmtable.h \ | bmtable.c \ | combox.h \ | combox.C \ | [.] | This somehow does not look sound To me it looks perfectly sound... And where should 'combox.C' reside? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: autogen.sh warnings
Andre Poenitz [EMAIL PROTECTED] writes: | On Thu, May 16, 2002 at 01:16:49PM +0200, Lars Gullik Bjønnes wrote: automake version please. I 1.5 without problems. | 1.4-p5 | Should I upgrade? Perhaps (proberly), but can we first try to find out what the real problem is with 1.4? -- Lgb
Re: make rpmdist
Andre Poenitz [EMAIL PROTECTED] writes: | On Thu, May 16, 2002 at 01:19:54PM +0200, Lars Gullik Bjønnes wrote: |nodist_libqt2xforms_la_SOURCES = \ |bmtable.h \ |bmtable.c \ |combox.h \ |combox.C \ | [.] | This somehow does not look sound To me it looks perfectly sound... | And where should 'combox.C' reside? Look lower and see the link_files target. It is possible that on your bot it should be $(nodist_libqt2xforms_la_OBJECTS). -- Lgb
Re: autogen.sh warnings
On Thu, May 16, 2002 at 01:31:06PM +0200, Lars Gullik Bjønnes wrote: Perhaps (proberly), but can we first try to find out what the real problem is with 1.4? Too late... I just installed 1.6.1 (but I can revert an probably will since this bails out with: poenitz@millo:/usr/src/lyx/lyx-devel ./autogen.sh Locating GNU m4... found: m4 Generate acinclude.m4... done. Building macros... . aclocal: configure.in: : macro `AM_FUNC_ERROR_AT_LINE' not found in library lib/reLyX sigc++ done. Building config header template... . autoheader: error: AC_CONFIG_HEADERS not found in configure.in sigc++ done. Building Makefile templates... . configure.in:19: no proper implementation of AM_INIT_AUTOMAKE was found, configure.in:19: probably because aclocal.m4 is missing... configure.in:19: You should run aclocal to create this file, then configure.in:19: run automake again. configure.in:5: required file `src/config.h.in' not found /usr/share/automake-1.6/am/compile.am: LIBS was set with `+=' and is now set with `=' /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL automake: src/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' src/frontends/Makefile.am:7: library used but `LIBTOOL' not defined in `configure.in' /usr/share/automake-1.6/am/compile.am: LIBS was set with `+=' and is now set with `=' /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL automake: src/frontends/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: config/kde.m4
Garst R. Reese [EMAIL PROTECTED] writes: | shouldn't this file get nuked? Yes it should. (unless some qt2 stuff uses things from it) -- Lgb
Re: autogen.sh warnings
Andre Poenitz [EMAIL PROTECTED] writes: | On Thu, May 16, 2002 at 01:31:06PM +0200, Lars Gullik Bjønnes wrote: Perhaps (proberly), but can we first try to find out what the real problem is with 1.4? | Too late... I just installed 1.6.1 (but I can revert an probably will since | this bails out with: mmm... that jump was a bit large. -- Lgb
Re: make rpmdist
On Thu, May 16, 2002 at 01:30:28PM +0200, Lars Gullik Bjønnes wrote: Look lower and see the link_files target. It is possible that on your bot it should be $(nodist_libqt2xforms_la_OBJECTS). Well, it is just $(libqt2xforms_la_OBJECTS) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
Andre Poenitz [EMAIL PROTECTED] writes: | On Thu, May 16, 2002 at 01:30:28PM +0200, Lars Gullik Bjønnes wrote: Look lower and see the link_files target. It is possible that on your bot it should be $(nodist_libqt2xforms_la_OBJECTS). | Well, it is just $(libqt2xforms_la_OBJECTS) Yes, and: quote It is possible that on your bot it should be $(nodist_libqt2xforms_la_OBJECTS). /quote s/bot/box/ -- Lgb
Re: make rpmdist
On Thu, May 16, 2002 at 01:30:28PM +0200, Lars Gullik Bjønnes wrote: Look lower and see the link_files target. It is possible that on your bot it should be $(nodist_libqt2xforms_la_OBJECTS). The problem seems to be that automake fails and link_files is not called afterwards. If I touch the Makefile in order not to trigger the automake run, 'make link_files' works. But even then 'make dist' aborts with: make[4]: Entering directory `/usr/src/lyx/lyx-devel/src/frontends/qt2/xforms' make[4]: *** No rule to make target `libqt2xforms.la.c', needed by `distdir'. Stop. libqt2xforms.la: link_files $(libqt2xforms_la_OBJECTS) But 'libqt2xforms.la.c' is an unusal file name, isn't it? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
On Thu, May 16, 2002 at 02:02:37PM +0200, Lars Gullik Bjønnes wrote: It is possible that on your bot it should be $(nodist_libqt2xforms_la_OBJECTS). | Well, it is just $(libqt2xforms_la_OBJECTS) Yes, and: quote It is possible that on your bot it should be $(nodist_libqt2xforms_la_OBJECTS). /quote Aehm.. I am lost. I have: libqt2xforms.la: link_files $(libqt2xforms_la_OBJECTS) link_files: for i in $(nodist_libqt2xforms_la_SOURCES); do \ ln -sf $(top_srcdir)/src/frontends/xforms/$$i . ; \ done So there is a 'nodist' in the 'link_files' target, but it's '...SOURCES' there, not '...OBJECTS'. What should this look like? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
Andre Poenitz [EMAIL PROTECTED] writes: | On Thu, May 16, 2002 at 02:02:37PM +0200, Lars Gullik Bjønnes wrote: It is possible that on your bot it should be $(nodist_libqt2xforms_la_OBJECTS). | Well, it is just $(libqt2xforms_la_OBJECTS) Yes, and: quote It is possible that on your bot it should be $(nodist_libqt2xforms_la_OBJECTS). /quote | Aehm.. I am lost. I have: | libqt2xforms.la: link_files $(libqt2xforms_la_OBJECTS) | link_files: | for i in $(nodist_libqt2xforms_la_SOURCES); do \ | ln -sf $(top_srcdir)/src/frontends/xforms/$$i . ; \ | done | So there is a 'nodist' in the 'link_files' target, but it's '...SOURCES' | there, not '...OBJECTS'. | What should this look like? Just as it does now. -- Lgb
Re: make rpmdist
Andre Poenitz [EMAIL PROTECTED] writes: | On Thu, May 16, 2002 at 01:30:28PM +0200, Lars Gullik Bjønnes wrote: Look lower and see the link_files target. It is possible that on your bot it should be $(nodist_libqt2xforms_la_OBJECTS). | The problem seems to be that automake fails and link_files is not called | afterwards. | If I touch the Makefile in order not to trigger the automake run, | 'make link_files' works. | But even then 'make dist' aborts with: | make[4]: Entering directory | `/usr/src/lyx/lyx-devel/src/frontends/qt2/xforms' | make[4]: *** No rule to make target `libqt2xforms.la.c', needed by | `distdir'. Stop. | libqt2xforms.la: link_files $(libqt2xforms_la_OBJECTS) | But 'libqt2xforms.la.c' is an unusal file name, isn't it? And you are sure you do not have any strange .deps or .libs dirs w/files? -- Lgb
Make fails with cxx + lyxstring
I do not know whether anybody cares, but compilation fails with
lyxstring and compaq cxx as follows:
mycxx -DHAVE_CONFIG_H -I. -I../../../lyx-devel/src/support -I../../src
-I../../../lyx-devel/src/support/../ -I../../../lyx-devel -I../..
-I../../../lyx-devel/boost -I../../../lyx-devel/src/cheaders -I/usr/local/include -g
-c -MD ../../../lyx-devel/src/support/lyxstring.C
cxx: Error: ../../../lyx-devel/src/support/lyxstring.C, line 1764: class
std::basic_istreamchar, std::char_traitschar has no member
ipfx0
if (is.ipfx0()) {
---^
cxx: Error: ../../../lyx-devel/src/support/lyxstring.C, line 1786: class
std::basic_istreamchar, std::char_traitschar has no member
isfx
is.isfx();
---^
cxx: Info: 2 errors detected in the compilation of
../../../lyx-devel/src/support/lyxstring.C.
As far as I understand these ipfx0() and isfx() methods are nowhere to
be found in the standard. If this is intended, compilation with
lyxstring should only be allowed with gcc.
JMarc
Re: make rpmdist
On Thu, May 16, 2002 at 02:46:04PM +0200, Lars Gullik Bjønnes wrote: And you are sure you do not have any strange .deps or .libs dirs w/files? This is 'rm -rf lyx-devel lyx-build ; cvs co lyx-devel ; cd lyx-devel ; ./autogen ; cd ../lyx-build ; ../lyx-devel/configure' [no script, typed by hand, but there should be no trace of old stuff] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: wrappers for xforms cont.
On Thursday 16 May 2002 6:20 am, Allan Rae wrote: I'd like to see what you come up with instead in QPreferences though... I don't believe it! You are proposing to work around the abuse of input() by adding an extra way of handling inputs (what you euphamistically call Suspects) while retaining the overuse and abuse of input(). Why not make a cleaner separation of the callbacks the widgets use so that input() doesn't get called by command/control widgets but only by input widgets (ones which may be able to have an invalid value). That way you separate the code in the BC so you handle like-with-like instead of a heterogeneous mix like it is now. *And* you no longer need to pass bogus values to the BC. Personally, I think BC changes should not be done in the 1.3cvs (partly to keep the cycle shorter, partly to work out what hierarchy reworking is needed and then figure out what/how a BC should work). But you are writing code and I am writing a thesis so you ultimately get to choose. Allan. (ARRae) Why don't you read the bloody code before talking a pile of crap? There are no callbacks, only signals. There is no input, only multiple slots. Angus
Re: Make fails with cxx + lyxstring
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| I do not know whether anybody cares, but compilation fails with
| lyxstring and compaq cxx as follows:
| mycxx -DHAVE_CONFIG_H -I. -I../../../lyx-devel/src/support -I../../src
|-I../../../lyx-devel/src/support/../ -I../../../lyx-devel -I../..
|-I../../../lyx-devel/boost -I../../../lyx-devel/src/cheaders -I/usr/local/include -g
|-c -MD ../../../lyx-devel/src/support/lyxstring.C
| cxx: Error: ../../../lyx-devel/src/support/lyxstring.C, line 1764: class
| std::basic_istreamchar, std::char_traitschar has no member
| ipfx0
| if (is.ipfx0()) {
| ---^
| cxx: Error: ../../../lyx-devel/src/support/lyxstring.C, line 1786: class
| std::basic_istreamchar, std::char_traitschar has no member
| isfx
| is.isfx();
| ---^
| cxx: Info: 2 errors detected in the compilation of
|../../../lyx-devel/src/support/lyxstring.C.
| As far as I understand these ipfx0() and isfx() methods are nowhere to
| be found in the standard. If this is intended, compilation with
| lyxstring should only be allowed with gcc.
and older dec compilers I guess...
This will not be fixed before 1.2.1.
--
Lgb
Re: make rpmdist
I get a step further if I replace the 'noinst_' prefix with 'EXTRA_' but I really don't know what I am doing there... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Make fails with cxx + lyxstring
Lars Gullik Bjønnes wrote: Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | As far as I understand these ipfx0() and isfx() methods are nowhere to | be found in the standard. If this is intended, compilation with | lyxstring should only be allowed with gcc. and older dec compilers I guess... It is not really a matter of 'older', but of funky GNU extension. I thought you were a standards guy. This will not be fixed before 1.2.1. This is fine with me. JMarc
Re: make rpmdist
Andre Poenitz [EMAIL PROTECTED] writes: | On Thu, May 16, 2002 at 02:46:04PM +0200, Lars Gullik Bjønnes wrote: And you are sure you do not have any strange .deps or .libs dirs w/files? | This is 'rm -rf lyx-devel lyx-build ; cvs co lyx-devel ; cd lyx-devel ; | ./autogen ; cd ../lyx-build ; ../lyx-devel/configure' | [no script, typed by hand, but there should be no trace of old stuff] Then it is your version of automake, I use: rpm -q automake automake-1.5-8 -- Lgb
Re: make rpmdist
Andre Poenitz [EMAIL PROTECTED] writes: | I get a step further if I replace the 'noinst_' prefix with 'EXTRA_' but I | really don't know what I am doing there... That is not where you want to change things. -- Lgb
Re: Make fails with cxx + lyxstring
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | As far as I understand these ipfx0() and isfx() methods are nowhere to | be found in the standard. If this is intended, compilation with | lyxstring should only be allowed with gcc. and older dec compilers I guess... | It is not really a matter of 'older', but of funky GNU extension. | I thought you were a standards guy. Yes I am: Ditch lyxstring now! -- Lgb
Re: Make fails with cxx + lyxstring
Lars Gullik Bjønnes wrote: | It is not really a matter of 'older', but of funky GNU extension. | I thought you were a standards guy. Yes I am: Ditch lyxstring now! Tssk, tssk... You really need this bit of vacation. JMarc -- - Jean-Marc Lasgouttes, Projet MEVAL, INRIA, France e-mail : [EMAIL PROTECTED]
Re: make rpmdist
On Thu, May 16, 2002 at 03:06:15PM +0200, Lars Gullik Bjønnes wrote: rpm -q automake automake-1.5-8 Ok. 1.5.1 now. Building Makefile templates... . src/Makefile.am:12: LIBS was set with `+=' and is now set with `=' src/frontends/Makefile.am:12: LIBS was set with `+=' and is now set with `=' lib/reLyX sigc++ done. Building configure... But it seems to go further, 'make dist' works, but 'make rpmdist' fails with Name field must be present in package: (main package) Version field must be present in package: (main package) Release field must be present in package: (main package) Summary field must be present in package: (main package) Group field must be present in package: (main package) License field must be present in package: (main package) Apart from that, there seem to be too much make dependencies. 'msgmerge' is _always_ run etc... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
RE: Small bug fixes for the next LyX release
Hello PAP, I send my answer to lyx-devel too, because I do not have much time right now. I do not understand why the change to kluwer.layout may help figure captions, but maybe someone else will :) Concerning latexconfig.yx, I think the problem you see has been corrected some time ago. Did you run EditReconfigure? JMarc PS: I am not working on scilab myself, but I now a few people who do, and this software certainly rocks :) -Original Message- From: PAP To: Jean-Marc Lasgouttes Sent: 14/05/02 16:18 Subject: Small bug fixes for the next LyX release Hello, I have downloaded LyX version 1.2.0pre5 and I have found that two small bugs concerning my kluwer layout still exist. I have already sended the bug fixes three months ago, but they are probably lost. The bug fixes have as follows. (1) Figure captions are not displayed correctly. The attached kluwer.layout file corrects this bug (at least in LyX 1.1.6fix4). (2) The LaTeXConfig.lyx file has an empty subsection just before the kluwer subsection. This is because there are two (instead of one) \layout Subsection lines in the LaTeXConfig.lyx.in file. Please delete one of them. By the way, you will be probably happy to know that I have recently published a paper which uses a large Scilab program for computing rotating magnetic white dwarf models [International Journal of Modern Physics, 13 (3), 297]. In the paper (written in LyX, of course), I have included some information about scientific computing with Scilab. Both LyX and Scilab are excellent programs. Keep up the good work! Panayotis Papasotiriou Post-doctoral researcher University of Patras, Greece
Re: config/kde.m4
On Thu, May 16, 2002 at 01:50:26PM +0200, Lars Gullik Bjønnes wrote: (unless some qt2 stuff uses things from it) No. Nuke away (after ignoring my nuking patch twice I believe :P) john -- It is very difficult to prophesy, especially when it pertains to the future. - Patrick Kurzawe
1.2p5 vs. 1.1.6: ERT issues
Hi all,
I just fell across a problem when I loaded an old (1.1.6) file into
lyx 1.2pre5:
It's a very ugly file, as I had to work alot with ERT. The old file
contained
\latex latex
\backslash
begin{multicols*}{2}[
\backslash
section*{
\color blue
{
\backslash
Large
\backslash
textrm{
\latex default
Introduction
\latex latex
\color default
}}}]
\layout Standard
which correctly produces the following tex code:
\begin{multicols*}{2}[\section*{\textcolor{blue}{{\Large\textrm{Introduction]
Loading and saving it with 1.2pre5 ends up with
\begin_inset ERT
status Collapsed
\layout Standard
\backslash
begin{multicols*}{2}[
\backslash
section*{{
\backslash
Large
\backslash
textrm{
\end_inset
\color blue
Introduction
\begin_inset ERT
status Collapsed
\layout Standard
}}}]
\end_inset
The \color default somehow didn't make it through the conversion, and
consequently this gets translated into
\begin{multicols*}{2}[\section*{{\Large\textrm{\textcolor{blue}{Introduction}}}]}
As you may recognize, the last two braces are exchanged, i.e., it's ]}
instead of }], and therefore latex bails out with sometimes very
strange messages :-(
Pit
--
Dr. Peter Pit Suetterlin http://www.astro.uu.nl/~suetter
Sterrenkundig Instituut Utrecht
Tel.: +31 (0)30 253 5225 [EMAIL PROTECTED]
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 03:20:08PM +1000, Allan Rae wrote: (partly to keep the cycle shorter, partly to work out what hierarchy I'm glad to hear I'm not the only one worried about 1.3. With the current stuff slated for it, it won't be out until 2004 :( regards john -- It is very difficult to prophesy, especially when it pertains to the future. - Patrick Kurzawe
Re: make rpmdist
On Thu, May 16, 2002 at 03:35:36PM +0200, Andre Poenitz wrote: Ok. 1.5.1 now. Where do we document this ? Thou must use 1.5.1. No more, no less. 1.5.1 must be the number thou must use, and the number of the use must be 1.5.1. 1.6 shalt thou not use, nor either use thou 1.4, excepting that thou then proceed to 1.5.1 Apologies to everyone. Name field must be present in package: (main package) And are they ? (in spec file) regards john -- It is very difficult to prophesy, especially when it pertains to the future. - Patrick Kurzawe
Re: wrappers for xforms cont.
On Thursday 16 May 2002 3:21 pm, John Levon wrote: On Thu, May 16, 2002 at 03:20:08PM +1000, Allan Rae wrote: (partly to keep the cycle shorter, partly to work out what hierarchy I'm glad to hear I'm not the only one worried about 1.3. With the current stuff slated for it, it won't be out until 2004 :( Isn't that what branches are for? Why don't we set up a GUII branch and play there. Ditto André/Jürgen could set up a RewriteCursorCodeToUseMetrics branch. It isn't too hard to maintain a branch against changes in head if the merging of changes in head into the branch is done regularly. Thereafter, merging of the branch back into head can be fraught with difficulties, but the alternative, creating a diff file and applying that is dead easy. I really think we should be making more use of branches. Angus
Re: make rpmdist
On Thu, May 16, 2002 at 11:12:18AM +0200, Andre Poenitz wrote: Is there anything special required to run this? I was trying it for the first time and got soon stuck with make[4]: Entering directory `/usr/src/lyx/lyx-devel/src/frontends/qt2/xforms' make[4]: *** No rule to make target `libqt2xforms.la.c', needed by `distdir'. Andre' ``make rpmdist'' is used by my automated daily builds all the time. No problems here. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92) msg38066/pgp0.pgp Description: PGP signature
Re: make rpmdist
On Thu, May 16, 2002 at 02:52:14PM +0200, Andre Poenitz wrote: On Thu, May 16, 2002 at 02:46:04PM +0200, Lars Gullik Bjønnes wrote: And you are sure you do not have any strange .deps or .libs dirs w/files? This is 'rm -rf lyx-devel lyx-build ; cvs co lyx-devel ; cd lyx-devel ; ./autogen ; cd ../lyx-build ; ../lyx-devel/configure' [no script, typed by hand, but there should be no trace of old stuff] Ah, yes. I know the problem, but not the fix. You have to do your make rpmdist in the CVS checkout directory, it does not work in ../lyx-build for reasons that I can not fathom. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92) msg38067/pgp0.pgp Description: PGP signature
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 03:33:50PM +0100, Angus Leeming wrote: Isn't that what branches are for? Why don't we set up a GUII branch and play there. Ditto André/Jürgen could set up a RewriteCursorCodeToUseMetrics branch. It isn't too hard to maintain a branch against changes in head if the merging of changes in head into the branch is done regularly. But it won't get tested as much as if it went in the main line. There are quite few things planned that will break everything. So I'd suggest everybody gets two months to put in his favourite changes, of course trying not to break to much stuff, but not too worried if some minor stuff gets broken, either. In the end everything will be a big mess, and we declare fix up time, i.e. try to re-assemble the pieces and get it running again. Not exactly a freeze, but sort of cooling down things. New stuff could be added in this phase if it is local. Several branches would lead to the same situation as we had now: Some group is a bit late and everybody else sits there and waits. Not nice. No fun. I really think we should be making more use of branches. I don't think so. Unless of course, I did not understand that whole branch business (which might well be) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
On Thu, May 16, 2002 at 03:27:09PM +0100, John Levon wrote: And are they ? (in spec file) Where is the spec file anyway? (I have not used 'rpm -ta' yet) development/lyx.spec? There isn't any in the .tar.gz... How does rpm now what spec file to use? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
On Thu, May 16, 2002 at 05:01:31PM +0200, Andre Poenitz wrote: On Thu, May 16, 2002 at 03:27:09PM +0100, John Levon wrote: And are they ? (in spec file) Where is the spec file anyway? (I have not used 'rpm -ta' yet) development/lyx.spec? There isn't any in the .tar.gz... Yes, there is one in the tarball. How does rpm now what spec file to use? It looks for a spec file in the tarball. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92) msg38070/pgp0.pgp Description: PGP signature
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 03:33:50PM +0100, Angus Leeming wrote: Isn't that what branches are for? To a degree. But big changes like GUII and not going to play well with other big changes. Why don't we set up a GUII branch and play there. Yes please, at least temporarily. I need some help unbreaking things, especially in xforms. branch. It isn't too hard to maintain a branch against changes in head if the merging of changes in head into the branch is done regularly. Thereafter, But it does get difficult where you have multiple branches, and you can't do a multi-way merge. What happens if Andre's branch modifies a file that doesn't even exist in GUII ? I really think we should be making more use of branches. Yes, probably regards john -- It is very difficult to prophesy, especially when it pertains to the future. - Patrick Kurzawe
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 04:56:01PM +0200, Andre Poenitz wrote: In the end everything will be a big mess, and we declare fix up time, Isn't this what happened with the abandoned development tree ? I would much prefer trying to draw up a list of planned major and even minor changes, and trying to keep to it. regards john -- It is very difficult to prophesy, especially when it pertains to the future. - Patrick Kurzawe
Re: wrappers for xforms cont.
On Thursday 16 May 2002 4:18 pm, John Levon wrote: On Thu, May 16, 2002 at 03:33:50PM +0100, Angus Leeming wrote: Isn't that what branches are for? To a degree. But big changes like GUII and not going to play well with other big changes. Why don't we set up a GUII branch and play there. Do we need Lars to set up the branch for us, or can we do this now? Yes please, at least temporarily. I need some help unbreaking things, especially in xforms. We should gradually filter your own personal tree into the branch. Things like today we're going to move the minibuffer behind the frontends firewall. Once we've got that working, we'd move onto the next bit of your tree. It'll be a bit painful to start with, but will mean that we don't get stuck with nasty horrible and difficult to find bugs all over the place. For your tree also read my wrappers tree. Slow but sure is the way to go here I think. Angus
Re: make rpmdist
On Thu, May 16, 2002 at 08:16:52AM -0700, Kayvan A. Sylvan wrote: How does rpm now what spec file to use? It looks for a spec file in the tarball. Ok. It works when build with sourcedir == builddir and automake 1.5 (neither 1.4 nor 1.6). Should be documented somehow. Maybe even some kind of 'assert' in the make target for 'rpmdist'. Andre' PS: I've put a lyx-1.2.0pre5-1-suse73.i386.rpm into yur incoming/forlyx. Actually it was called lyx-1.3.0cvs-1.i386.rpm, but we are not in the 1.3.0series, are we? -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
On Thursday 16 May 2002 4:36 pm, Andre Poenitz wrote: PS: I've put a lyx-1.2.0pre5-1-suse73.i386.rpm into yur incoming/forlyx. Actually it was called lyx-1.3.0cvs-1.i386.rpm, but we are not in the 1.3.0series, are we? Since Lars moved 1.2 off into it's own branch, we are yes. Angus
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 04:19:34PM +0100, John Levon wrote: I would much prefer trying to draw up a list of planned major and even minor changes, and trying to keep to it. Ok... a few things on my agenda: global - context sensitive keybindings - better .tex - .lyx coversion - the cursor stuff - unify real insets and mathed's insets - David's preview stuff mathed only - fill in gaps in AMS support - further work on math-extern - reduce memory consumption Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
On Thu, May 16, 2002 at 05:36:16PM +0200, Andre Poenitz wrote: On Thu, May 16, 2002 at 08:16:52AM -0700, Kayvan A. Sylvan wrote: How does rpm now what spec file to use? It looks for a spec file in the tarball. Ok. It works when build with sourcedir == builddir and automake 1.5 (neither 1.4 nor 1.6). Should be documented somehow. Maybe even some kind of 'assert' in the make target for 'rpmdist'. Andre' PS: I've put a lyx-1.2.0pre5-1-suse73.i386.rpm into yur incoming/forlyx. Actually it was called lyx-1.3.0cvs-1.i386.rpm, but we are not in the 1.3.0series, are we? It is now in ftp://ftp.sylvan.com/pub/lyx/devel -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92) msg38077/pgp0.pgp Description: PGP signature
Re: make rpmdist
I haven't paid any attention to these different make targets. Could someone tell me which one I should use if I wanted to make a tarball for the DEC Alpha users out there? make dist? And can I build that with src dir != build dir? Angus
Re: make rpmdist
On Thu, May 16, 2002 at 08:56:51AM -0700, Kayvan A. Sylvan wrote: It is now in ftp://ftp.sylvan.com/pub/lyx/devel I just noticed that the dependencies are redhat like. There is neither tetex-latex nor tetex-dvi on SuSE, the stuff is in te_latex and tetex proper. [OTOH, SuSE users a used to --nodeps when installing rpms ;-}] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 04:29:19PM +0100, Angus Leeming wrote: We should gradually filter your own personal tree into the branch. Would that it were so easy, unless you are prepared to take merges that leave an uncompilable lyx. The nature of the beast makes it near impossible to split things up into compilable chunks. though logical is easy (this is the set of changes for lyxfont.h becoming frontends/font_metrics.h etc.) john -- It is very difficult to prophesy, especially when it pertains to the future. - Patrick Kurzawe
Re: wrappers for xforms cont.
On Thursday 16 May 2002 5:23 pm, John Levon wrote: On Thu, May 16, 2002 at 04:29:19PM +0100, Angus Leeming wrote: We should gradually filter your own personal tree into the branch. Would that it were so easy, unless you are prepared to take merges that leave an uncompilable lyx. The nature of the beast makes it near impossible to split things up into compilable chunks. though logical is easy (this is the set of changes for lyxfont.h becoming frontends/font_metrics.h etc.) That's what I meant. One logical change at a time, then does it work with xforms and with Qt? Great, let's make the next logical change. Angus
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 05:28:10PM +0100, Angus Leeming wrote: That's what I meant. One logical change at a time, then does it work with xforms and with Qt? Great, let's make the next logical change. But how can we tell it works without compiling and testing ? Anyway, Qt is NOT important right now. I know what generalisations I've had to make so far, so getting xforms to be happy with those is the priority. Qt can stay broken until later (though of course it works in my tree). Currently there a re a number of things that are just broken - minibuffer is commented out, various other things don't work, etc. regards john -- It is very difficult to prophesy, especially when it pertains to the future. - Patrick Kurzawe
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 05:43:00PM +0200, Andre Poenitz wrote: - context sensitive keybindings Already this is likely to clash with GUII :( How seriously I don't know. - better .tex - .lyx coversion Luckily independent (you mean python-relyx yes ?) - the cursor stuff MASSIVE change ... - unify real insets and mathed's insets I suppose this is big too. - David's preview stuff Potentially high risk ... mathed only - fill in gaps in AMS support - further work on math-extern - reduce memory consumption these are all OK :) I suppose we just have to be careful not to step on other's toes, so more discussion about patches etc. would be good. For example, a while back you wanted to change lyxfont.h for some reason, but that file is dead and completely different in GUII tree... because you mentioned on the list I could point that out... john -- It is very difficult to prophesy, especially when it pertains to the future. - Patrick Kurzawe
bug in cvs
can someone confirm?
- open new doc
- choose document-class-book(koma class)
- choose document-language-spanish
- write a word
- dvi-view gives an error
the command
\addto\extrasspanish{\bbl@deactivate{~}}
is unknown
Herbert
--
http://www.lyx.org/help/
Re: wrappers for xforms cont.
On Thursday 16 May 2002 5:43 pm, John Levon wrote: On Thu, May 16, 2002 at 05:28:10PM +0100, Angus Leeming wrote: That's what I meant. One logical change at a time, then does it work with xforms and with Qt? Great, let's make the next logical change. But how can we tell it works without compiling and testing ? Well that's it. I'd like to get each logical change up and running properly. Anyway, Qt is NOT important right now. I know what generalisations I've had to make so far, so getting xforms to be happy with those is the priority. Qt can stay broken until later (though of course it works in my tree). Currently there a re a number of things that are just broken - minibuffer is commented out, various other things don't work, etc. In the case of the minibuffer, the challenge we should set ourselves first is a clean controller/view split. Incidentally, why didn't you try a combox(FL_COMBOX_INPUT)? I know, like me, you hadn't discovered it til now ;-) Angus
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 06:00:38PM +0100, Angus Leeming wrote: But how can we tell it works without compiling and testing ? Well that's it. I'd like to get each logical change up and running properly. This will certainly be slow, although I doubt it will be sure. I suppose this is the proper thing to do, but I estimate it will roughly triple the integration effort. In the case of the minibuffer, the challenge we should set ourselves first is a clean controller/view split. Things like this are very easy in comparison to something like the WorkArea changes. Incidentally, why didn't you try a combox(FL_COMBOX_INPUT)? I know, like me, you hadn't discovered it til now ;-) coo :) john -- It is very difficult to prophesy, especially when it pertains to the future. - Patrick Kurzawe
Re: wrappers for xforms cont.
On Thursday 16 May 2002 6:01 pm, John Levon wrote: On Thu, May 16, 2002 at 06:00:38PM +0100, Angus Leeming wrote: But how can we tell it works without compiling and testing ? Well that's it. I'd like to get each logical change up and running properly. This will certainly be slow, although I doubt it will be sure. I suppose this is the proper thing to do, but I estimate it will roughly triple the integration effort. But will mean that you can take people along with you. Dumping a huge change on us will mean that you're the only one who knows what's going on at all. Remember, it's taken us two years to do the dialogs. They've been through a number of evolutions in the process and are much stronger for them. That means more than one person understanding what's going on. Not that the main window will take that long... A
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 06:14:05PM +0100, Angus Leeming wrote: But will mean that you can take people along with you. Dumping a huge change on us will mean that you're the only one who knows what's going on at all. Perhaps. But bear in mind that in fact the changes are conceptually very very simple. This is a first iteration of the design + implementation, it will no doubt change a lot more. I'm not strongly against a more measured approach, just we should be aware of the additional burden of doing this. Remember, it's taken us two years to do the dialogs. They've been through a number of evolutions in the process and are much stronger for them. That means more than one person understanding what's going on. Yes but for at least two points there were essentially monolithic changes, since everybody was too lazy to actually follow MVC tree :) So, Lars, can we have a branch ?? john -- It is very difficult to prophesy, especially when it pertains to the future. - Patrick Kurzawe
Re: wrappers for xforms cont.
On Thursday 16 May 2002 6:20 pm, John Levon wrote: So, Lars, can we have a branch ?? Hes' on holiday I believe. Why don't you see if you can create one and commit to it... Angus
CJK merge?
Would it seem a good idea to merge the CJK patch for support of multibyte character sets with the main trunk sometime in the near future (such as for 1.3)? Supporting a whole extra version of LyX is probably a pain in the rear. Moreover, merging it in would be a good step towards Unicode/Omega support. Philippmailto:[EMAIL PROTECTED] ___ Windows NT crashed / I am the Blue Screen of Death / No one hears your screams
Re: bug in cvs
-BEGIN PGP SIGNED MESSAGE- On Thursday 16 May 2002 18:53, Herbert Voss wrote: can someone confirm? No, working here. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQCVAwUBPOQRZbewfbDGmeqhAQGD0AQAiWs0Vcrb+9Z2qSkkFirMDidcToKfnNyt AkvkZEkPQX8mvpT5f9RViQ+dLY6F6wcbtLTShC/rq9ogBHNbg6UEB0Gph1BlgvC8 ZMOvXgFqPkCQ1qNZVBjkKh5hjx1dSbCMYJYT2QvI+bBKFVM+hmp4GD/xRkE472Gt oUxQrwVAZfo= =6oO2 -END PGP SIGNATURE-
Re: bug in cvs
Kornel Benko wrote: -BEGIN PGP SIGNED MESSAGE- On Thursday 16 May 2002 18:53, Herbert Voss wrote: can someone confirm? No, working here. ok, I see, thanks Herbert -- http://www.lyx.org/help/
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 05:47:10PM +0100, John Levon wrote: On Thu, May 16, 2002 at 05:43:00PM +0200, Andre Poenitz wrote: - better .tex - .lyx coversion Luckily independent (you mean python-relyx yes ?) Yes. That's mine. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92) msg38094/pgp0.pgp Description: PGP signature
Re: CJK merge?
Philipp Reichmuth wrote: Would it seem a good idea to merge the CJK patch for support of multibyte character sets with the main trunk sometime in the near future (such as for 1.3)? No. The CJK patch is not something we want to see merged with its current status, and xforms-0. is not something CJK users feel comfortable. In xforms-0., the input context is private to the toolkit so that application programs cannot have an access. Which means the input method style is fixed to XIMPreeditNothing|XIMStatusNothing so that CJK inputs from keyboard to LyX circumvents through another window, which really is a pain especially your window manager intervene with focus changes. On the other hand, xforms-0. use XDrawString() for drawing text. LyX uses xforms method to draw text in menus and dialogs. So this must be rewritten with XmbDrawString() and co. In that case, since XFontSet unlike XFontStruct is not a property of the graphic context, the toolkit must keep track of the fonts in use. I am going to submit a patch for xforms when I can find a time, but on the second thought, an OS/2 support patch I sent a year and a half ago was not been incorporated in xforms-0. Now the CJK patch is completely locale based and use Xmb** functions to draw CJK text on the main LyX window. Considering that the multi-locale support in X is extremely fragile, the multilingual document support would have to be dropped if we were to merge CJK. Here, unicode based text drawing must be implemented and LyX must take care of certain amount of locale stuffs. Moreover, merging it in would be a good step towards Unicode/Omega support. Notice Omega, both in its core engine and PostScript driver does not support Unicode fonts at all. It is their design decision not to support any fonts which contains more than 256 glyphs.
Re: CJK merge?
On Fri, May 17, 2002 at 11:18:12AM +0900, Shigeru Miyata wrote: I am going to submit a patch for xforms when I can find a time, but on the second thought, an OS/2 support patch I sent a year and a half ago was not been incorporated in xforms-0. This was before the proper merge of patches - wait until the release candidate, you may find your patch included there. regards john -- It is very difficult to prophesy, especially when it pertains to the future. - Patrick Kurzawe
Re: Non-float graphics sizing sort of bug
Herbert et al, This works on my file. I now get the same output as 1.1.6. Haven't had an extensive play with it though, so I can't comment on anything else the patch does. Rod On Thu, 16 May 2002, Herbert Voss wrote: Rod Pinna wrote: Just opened a file of mine, from 1.1.6fix4, which has a number of non-floating eps files. The output from latex has these is incorrectly sized. The graphics are scaled to a percentage of the paper width. Actually, I see, the new version has a text% option, which seems to match the output of the previous % of page option. Not sure if I should call it a bug then...possibly the import should convert the 1.1.6 page width to the 1.2.0 text width. Rod, please try this patch Herbert -- http://www.lyx.org/help/ _ rod | Beneath the waves, the waves / That's where I will be / | I'm going to see the cow beneath the sea. | They Might Be Giants, Lincoln
Re: wrappers for xforms cont.
On Thu, 16 May 2002, Andre Poenitz wrote: On Thu, May 16, 2002 at 03:33:50PM +0100, Angus Leeming wrote: Isn't that what branches are for? Why don't we set up a GUII branch and play there. Ditto André/Jürgen could set up a RewriteCursorCodeToUseMetrics branch. It isn't too hard to maintain a branch against changes in head if the merging of changes in head into the branch is done regularly. But it won't get tested as much as if it went in the main line. The idea of a branch is to get some project mostly done -- so it works-for-me and anyone who cares to test it -- and that code is then merged into the _stable_ trunk and we fix all the ripples. This way there are small ripples not big waves caused by several projects thrashing about in the trunk. (like my mixed metaphors?) It does require a change of mindset but it also provides for more scope in project management. Lars/We gets to control when branches get merged and in what order. It also means we can set a date of the next release and set a cutoff for merging branches of 4 to 6 weeks before that date. There are quite few things planned that will break everything. All the more reason why they should be in separate branches or we do a bit of project management and work out the dependencies between projects and try to resolve those issues first (whether it be in a branch or in the trunk). So I'd suggest everybody gets two months to put in his favourite changes, of course trying not to break to much stuff, but not too worried if some minor stuff gets broken, either. In the end everything will be a big mess, and we declare fix up time, i.e. try to re-assemble the pieces and get it running again. Not exactly a freeze, but sort of cooling down things. New stuff could be added in this phase if it is local. Fix up time is a major pain because half way through a project that breaks everything one or more developers gets extra work in their paid jobs (just like Lars and Jürgen last year) and everyone gets delayed. If said project-that-breaks-everything is in a branch the changes don't get lost, but they also don't delay the next release. Several branches would lead to the same situation as we had now: Some group is a bit late and everybody else sits there and waits. Not nice. No fun. If some group is late they miss the cut and have to wait for the next release. They don't actually stop the trunk from being usable. Allan. (ARRae)
Re: wrappers for xforms cont.
On Thu, 16 May 2002, Angus Leeming wrote: On Thursday 16 May 2002 6:20 am, Allan Rae wrote: [...] Allan. (ARRae) Why don't you read the bloody code before talking a pile of crap? Not all the pile was crap but after reading the code I now see that some of it might have been. There are no callbacks, only signals. There is no input, only multiple slots. If the various inputs are all tested in their respective slots (surely some of them can be invalid even for the code you have already changed -- rather than just returning without telling the BC that you found something invalid) and the complex widgets also tell the BC when a valid input was found (it'd be nice if they too declared invalid inputs instead of silently returning from the slot function) then the BC should already be in an appropriate state. At worst you only have relationships between widgets to check -- not widgets that form a super-widget as these are already taken care of by your slots. The widget-dependency/relationship testing should argueably be on a per-frontend basis since the widgets are frontend specific and as John pointed out different frontends might implement stuff in different ways. And this widget-dependency stuff is what the input() callback was originally meant to do (along with per-widget testing that you have now moved into slots). The code does look pretty but I wonder how much polishing is too much. Have you measured code size and compile speed changes with this new approach? Allan. (ARRae)
1.1.6 compatibility
reading the attached 1.1.6 file with latest cvs gives a lot of errors. maybe most of them are math-related?? Herbert -- http://www.lyx.org/help/ test.tgz Description: Binary data
[PATCH]Re: Non-float graphics sizing sort of bug
Rod Pinna wrote: This works on my file. I now get the same output as 1.1.6. Haven't had an extensive play with it though, so I can't comment on anything else the patch does. Just opened a file of mine, from 1.1.6fix4, which has a number of non-floating eps files. The output from latex has these is incorrectly sized. The graphics are scaled to a percentage of the paper width. Actually, I see, the new version has a text% option, which seems to match the output of the previous % of page option. Not sure if I should call it a bug then...possibly the import should convert the 1.1.6 page width to the 1.2.0 text width. Rod, please try this patch Lars, this patch (http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg38091.html) fixes a real bug. The only important fact is that we get two new vertical lengths: theight% and pheight% Otherwise we can't read 1.1.6-file in the right manner. textheight% and paperheight% maybe better, but than we have to change the width of most gui-choices. it should be applied to 1.2.0 -- http://www.lyx.org/help/
Re: wrappers for xforms cont.
On Thu, May 16, 2002 at 05:43:00PM +0200, Andre Poenitz wrote: On Thu, May 16, 2002 at 04:19:34PM +0100, John Levon wrote: I would much prefer trying to draw up a list of planned major and even minor changes, and trying to keep to it. Ok... a few things on my agenda: global - context sensitive keybindings - better .tex - .lyx coversion - the cursor stuff - unify real insets and mathed's insets - David's preview stuff mathed only - fill in gaps in AMS support - further work on math-extern - reduce memory consumption Andre' My 0.02 EUR: - User-definable floats (Herbert) - Optional arguments (short title versions) - Spreadsheet functionality (basic) in tabular - Something else I don't remember :-) Martin msg38102/pgp0.pgp Description: PGP signature
Re: PATCH pspell.m4
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | ChangeLog | 2002-05-15 Garst Reese <[EMAIL PROTECTED]> | * fix c boo boo | * fix to work with .so as well as .a or both.--- pspell.m4.save Wed May 15 |17:54:20 2002 | +++ pspell.m4 Wed May 15 20:49:46 2002 | @@ -31,12 +31,12 @@ |pspell_lib_found="Setting to $pspell_use_lib" | else |pspell_libs="/usr/lib /usr/lib/pspell /usr/local/lib /usr/local/lib/pspell" | - AC_FIND_FILE(libpspell.a,$pspell_libs,pspell_use_lib) | + AC_FIND_FILE(libpspell.a libpspell.so,$pspell_libs,pspell_use_lib) |pspell_lib_found="yes" | fi | | if test "$pspell_use_include" = "NO" || \ | - test "$pspell_use_include" = "NO"; then | + test "$pspell_use_lib" = "NO"; then |if test "$USE_PSPELL" = "yes"; then | USE_PSPELL="not found" |fi I do not think that this is the solution that we really want, on my box. libpspell is a libtool library: libpspell.la I do not know how other boxes does this, do they also have a libtool lib? I wonder why pspell.m4 does not use the regular machinery for finding libraries and header files. -- Lgb
Re: PATCH pspell.m4
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | "Garst R. Reese" wrote: | Oops, the ChangeLog was too incomplete | ChangeLog | 2002-05-15 Garst Reese <[EMAIL PROTECTED]> | * fix pspell.m4 c boo boo | * fix pspell.m4 to work with .so as well as .a or both. It really should have been: * (pspell.m4): c boo boo fix to work with .so as well as .a or both. But as I said we should also check for .la, and perhaps change the discovery functions a bit. -- Lgb
Re: Non-float graphics sizing sort of bug
Rod Pinna wrote:
> Just opened a file of mine, from 1.1.6fix4, which has a number of
> non-floating eps files. The output from latex has these is incorrectly
> sized. The graphics are scaled to a percentage of the paper width.
>
> In 1.1.6f4, the file is set to 85% of page. This produces the following
> tex
>
> {\centering \resizebox*{0.85\textwidth}{!}{\includegraphics...}
>
> In 1.2.0, the include is set to Width 85 page%, and the tex produced is
>
> \begin{center}\includegraphics[
> width=0.85\paperwidth]{filename}\end{center}
>
> Actually, I see, the new version has a "text%" option, which seems to
> match the output of the previous "% of page" option.
>
> Not sure if I should call it a bug then...possibly the import should
> convert the 1.1.6 page width to the 1.2.0 text width.
it's a real bug! And we don't have any vertical length in
the length-choice
Herbert
--
http://www.lyx.org/help/
rc1
I just created the 1.2.x branch, and just put rc1 out. On Rc1 I only want to fix blatant compilation errors or configure install errors, and only if the errors are important enough. The pspell fix does not cut it so far. I am leaving for the weekend + monday later today, so I do not want to release 1.2.0 right now, but rather put down next Wednesday as the release date, unless something unforeseen comes up. -- Lgb
make rpmdist
Is there anything special required to run this? I was trying it for the first time and got soon stuck with make[4]: Entering directory `/usr/src/lyx/lyx-devel/src/frontends/qt2/xforms' make[4]: *** No rule to make target `libqt2xforms.la.c', needed by `distdir'. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
Andre Poenitz <[EMAIL PROTECTED]> writes: | Is there anything special required to run this? > | I was trying it for the first time and got soon stuck with > > | make[4]: Entering directory `/usr/src/lyx/lyx-devel/src/frontends/qt2/xforms' | make[4]: *** No rule to make target `libqt2xforms.la.c', needed by | `distdir'. Then you have something fishy in your source/build tree or on your box, I use "make dist" "make distdir" and "make distcheck" all the time. Are you trying to compile with qt? a "rm -rf qt2" and then recheckout + autogen + configure would probably help. -- Lgb
Re: PATCH pspell.m4
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: > >> I do not think that this is the solution that we really want, on my >> box. libpspell is a libtool library: libpspell.la >> I do not know how other boxes does this, do they also have a libtool >> lib? >> >> I wonder why pspell.m4 does not use the regular machinery for finding >> libraries and header files. >> | I also have a libpspell.la. I have not a clue what the "regular | machinery" would be, AC_CHECK_LIB f.ex. | but at least this does not screw up. It would do | just as well to just look for libpspell.la tho. yes. perhaps .la .so .a then... -- Lgb
autogen.sh "warnings"
After a clean checkout I get Building Makefile templates... . src/frontends/qt2/xforms/Makefile.am:15: invalid unused variable name: `nodist_libqt2xforms_la_SOURCES' src/frontends/qt2/moc/Makefile.am:18: invalid unused variable name: `nodist_libqt2moc_la_SOURCES' src/frontends/qt2/ui/Makefile.am:19: invalid unused variable name: `nodist_libqt2ui_la_SOURCES' src/frontends/qt2/ui/moc/Makefile.am:17: invalid unused variable name: `nodist_libqt2uimoc_la_SOURCES' Is this necessary/intended? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
On Thu, May 16, 2002 at 11:20:59AM +0200, Lars Gullik Bjønnes wrote: > Then you have something fishy in your source/build tree or on your > box, I use "make dist" "make distdir" and "make distcheck" all the > time. 'make dist' already does not work on a clean check out. > Are you trying to compile with qt? No. > a "rm -rf qt2" and then recheckout + autogen + configure > would probably help. The directory frontends/qt2/xforms is empty but for a 'Makefile.am' which is not empty: include $(top_srcdir)/config/common.am noinst_LTLIBRARIES = libqt2xforms.la INCLUDES = -I$(top_srcdir)/src/ -I$(top_srcdir)/src/frontends/ \ $(SIGC_CFLAGS) -I$(top_srcdir)/images \ $(FRONTEND_INCLUDES) $(BOOST_INCLUDES) \ -I$(top_srcdir)/src/frontends/controllers if USE_BASIC_IMAGE_LOADER else XFORMSGIMAGE = xformsGImage.C xformsGImage.h endif nodist_libqt2xforms_la_SOURCES = \ bmtable.h \ bmtable.c \ combox.h \ combox.C \ [.] This somehow does not look sound Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: autogen.sh "warnings"
Andre Poenitz <[EMAIL PROTECTED]> writes: | After a clean checkout I get I never get that. | Building Makefile templates... | . | src/frontends/qt2/xforms/Makefile.am:15: invalid unused variable name: | `nodist_libqt2xforms_la_SOURCES' | src/frontends/qt2/moc/Makefile.am:18: invalid unused variable name: | `nodist_libqt2moc_la_SOURCES' | src/frontends/qt2/ui/Makefile.am:19: invalid unused variable name: | `nodist_libqt2ui_la_SOURCES' | src/frontends/qt2/ui/moc/Makefile.am:17: invalid unused variable name: | `nodist_libqt2uimoc_la_SOURCES' > > | Is this necessary/intended? automake version please. I 1.5 without problems. -- Lgb
Re: make rpmdist
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, May 16, 2002 at 11:20:59AM +0200, Lars Gullik Bjønnes wrote: >> Then you have something fishy in your source/build tree or on your >> box, I use "make dist" "make distdir" and "make distcheck" all the >> time. > | 'make dist' already does not work on a clean check out. > >> Are you trying to compile with qt? > | No. > >> a "rm -rf qt2" and then recheckout + autogen + configure >> would probably help. > | The directory frontends/qt2/xforms is empty but for a 'Makefile.am' which | is not empty: > | include $(top_srcdir)/config/common.am > | noinst_LTLIBRARIES = libqt2xforms.la > | INCLUDES = -I$(top_srcdir)/src/ -I$(top_srcdir)/src/frontends/ \ | $(SIGC_CFLAGS) -I$(top_srcdir)/images \ | $(FRONTEND_INCLUDES) $(BOOST_INCLUDES) \ | -I$(top_srcdir)/src/frontends/controllers > | if USE_BASIC_IMAGE_LOADER | else | XFORMSGIMAGE = xformsGImage.C xformsGImage.h | endif > | nodist_libqt2xforms_la_SOURCES = \ | bmtable.h \ | bmtable.c \ | combox.h \ | combox.C \ | [.] > > | This somehow does not look sound To me it looks perfectly sound... -- Lgb
Re: autogen.sh "warnings"
On Thu, May 16, 2002 at 01:16:49PM +0200, Lars Gullik Bjønnes wrote: > automake version please. > > I 1.5 without problems. 1.4-p5 Should I upgrade? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
On Thu, May 16, 2002 at 01:19:54PM +0200, Lars Gullik Bjønnes wrote: > | nodist_libqt2xforms_la_SOURCES = \ > | bmtable.h \ > | bmtable.c \ > | combox.h \ > | combox.C \ > | [.] > > > > > | This somehow does not look sound > > To me it looks perfectly sound... And where should 'combox.C' reside? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: autogen.sh "warnings"
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, May 16, 2002 at 01:16:49PM +0200, Lars Gullik Bjønnes wrote: >> automake version please. >> >> I 1.5 without problems. > | 1.4-p5 > | Should I upgrade? Perhaps (proberly), but can we first try to find out what the real problem is with 1.4? -- Lgb
Re: make rpmdist
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, May 16, 2002 at 01:19:54PM +0200, Lars Gullik Bjønnes wrote: >> |nodist_libqt2xforms_la_SOURCES = \ >> |bmtable.h \ >> |bmtable.c \ >> |combox.h \ >> |combox.C \ >> | [.] >> > >> > >> | This somehow does not look sound >> >> To me it looks perfectly sound... > | And where should 'combox.C' reside? Look lower and see the link_files target. It is possible that on your bot it should be $(nodist_libqt2xforms_la_OBJECTS). -- Lgb
Re: autogen.sh "warnings"
On Thu, May 16, 2002 at 01:31:06PM +0200, Lars Gullik Bjønnes wrote: > Perhaps (proberly), but can we first try to find out what the real problem is > with 1.4? Too late... I just installed 1.6.1 (but I can revert an probably will since this bails out with: poenitz@millo:/usr/src/lyx/lyx-devel > ./autogen.sh Locating GNU m4... found: m4 Generate acinclude.m4... done. Building macros... . aclocal: configure.in: : macro `AM_FUNC_ERROR_AT_LINE' not found in library lib/reLyX sigc++ done. Building config header template... . autoheader: error: AC_CONFIG_HEADERS not found in configure.in sigc++ done. Building Makefile templates... . configure.in:19: no proper implementation of AM_INIT_AUTOMAKE was found, configure.in:19: probably because aclocal.m4 is missing... configure.in:19: You should run aclocal to create this file, then configure.in:19: run automake again. configure.in:5: required file `src/config.h.in' not found /usr/share/automake-1.6/am/compile.am: LIBS was set with `+=' and is now set with `=' /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL automake: src/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' src/frontends/Makefile.am:7: library used but `LIBTOOL' not defined in `configure.in' /usr/share/automake-1.6/am/compile.am: LIBS was set with `+=' and is now set with `=' /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL automake: src/frontends/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: config/kde.m4
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | shouldn't this file get nuked? Yes it should. (unless some qt2 stuff uses things from it) -- Lgb
Re: autogen.sh "warnings"
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, May 16, 2002 at 01:31:06PM +0200, Lars Gullik Bjønnes wrote: >> Perhaps (proberly), but can we first try to find out what the real problem is >> with 1.4? > | Too late... I just installed 1.6.1 (but I can revert an probably will since | this bails out with: mmm... that jump was a bit large. -- Lgb
Re: make rpmdist
On Thu, May 16, 2002 at 01:30:28PM +0200, Lars Gullik Bjønnes wrote: > Look lower and see the link_files target. > > It is possible that on your bot it should be > $(nodist_libqt2xforms_la_OBJECTS). Well, it is just $(libqt2xforms_la_OBJECTS) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, May 16, 2002 at 01:30:28PM +0200, Lars Gullik Bjønnes wrote: >> Look lower and see the link_files target. >> >> It is possible that on your bot it should be >> $(nodist_libqt2xforms_la_OBJECTS). > | Well, it is just $(libqt2xforms_la_OBJECTS) Yes, and: >> It is possible that on your bot it should be >> $(nodist_libqt2xforms_la_OBJECTS). s/bot/box/ -- Lgb
Re: make rpmdist
On Thu, May 16, 2002 at 01:30:28PM +0200, Lars Gullik Bjønnes wrote: > Look lower and see the link_files target. > > It is possible that on your bot it should be > $(nodist_libqt2xforms_la_OBJECTS). The problem seems to be that automake fails and link_files is not called afterwards. If I touch the Makefile in order not to trigger the automake run, 'make link_files' works. But even then 'make dist' aborts with: make[4]: Entering directory `/usr/src/lyx/lyx-devel/src/frontends/qt2/xforms' make[4]: *** No rule to make target `libqt2xforms.la.c', needed by `distdir'. Stop. libqt2xforms.la: link_files $(libqt2xforms_la_OBJECTS) But 'libqt2xforms.la.c' is an unusal file name, isn't it? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
On Thu, May 16, 2002 at 02:02:37PM +0200, Lars Gullik Bjønnes wrote: > >> It is possible that on your bot it should be > >> $(nodist_libqt2xforms_la_OBJECTS). > > > | Well, it is just $(libqt2xforms_la_OBJECTS) > > Yes, and: > > > >> It is possible that on your bot it should be > >> $(nodist_libqt2xforms_la_OBJECTS). > Aehm.. I am lost. I have: libqt2xforms.la: link_files $(libqt2xforms_la_OBJECTS) link_files: for i in $(nodist_libqt2xforms_la_SOURCES); do \ ln -sf "$(top_srcdir)/src/frontends/xforms/$$i" . ; \ done So there is a 'nodist' in the 'link_files' target, but it's '...SOURCES' there, not '...OBJECTS'. What should this look like? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: make rpmdist
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, May 16, 2002 at 02:02:37PM +0200, Lars Gullik Bjønnes wrote: >> >> It is possible that on your bot it should be >> >> $(nodist_libqt2xforms_la_OBJECTS). >> > >> | Well, it is just $(libqt2xforms_la_OBJECTS) >> >> Yes, and: >> >> >> >> It is possible that on your bot it should be >> >> $(nodist_libqt2xforms_la_OBJECTS). >> > | Aehm.. I am lost. I have: > | libqt2xforms.la: link_files $(libqt2xforms_la_OBJECTS) > | link_files: | for i in $(nodist_libqt2xforms_la_SOURCES); do \ | ln -sf "$(top_srcdir)/src/frontends/xforms/$$i" . ; \ | done > | So there is a 'nodist' in the 'link_files' target, but it's '...SOURCES' | there, not '...OBJECTS'. > | What should this look like? Just as it does now. -- Lgb
