Making lyx with the kde frontend
Ok, I'm feeling pretty proud of myself. I've compiled and linked lyx with
the kde frontend. This has meant compiling the kde-1.1.2 libraries with DEC
cxx; straightforward, but tedious with all those "using std::xxx" and extern
"C" calls I've come to know and love ;-)
Incidentally, Jean-Marc, if you are interested but don't want to go through
the pain, I'll happily ftp the qt/kde libs.
When it came to configuring/compiling/linking lyx, again all went fairly
smoothly, but there are some bugs in the configure script which could be
removed.
The script with which I configured lyx is at the bottom of this letter.
You'll see that I specify explicitly where to find the cxx-compiled qt and
kde libs and header files. I think that configure should respect these. I
have a working version, compiled with gcc and retrieved from the kde ftp
site, of qt/kde installed on my machine in /usr/local/qt and /usr/local/kde
that I didn't want (couldn't) use. To ensure this was so, I had to hack the
configure script. Diff file is attached.
Finally, the src/Makefile defines the qt and kdelibraries as:
-lqt -lkdecore
This results in lots of "can't find symbol" errors. On the DEC the order of
these library declarations is important. They should be
-lkdecore -lqt
Hope that these comments are of some use.
Angus
#!/bin/sh
QTDIR=/usr/users/aleem/OTHERS_CODE/qt-1.44
export QTDIR
KDEDIR=/usr/users/aleem/OTHERS_CODE/kde-1.1.2
export KDEDIR
LYXDIR=/usr/users/aleem/OTHERS_CODE/lyx/devel
export LYXDIR
CC=deccc
export
CFLAGS=-O2
export CFLAGS
CXX=deccxx
export CXX
CXXFLAGS="-ptr $LYXDIR/lyx_cxx_repository -O2"
export CXXFLAGS
./configure --host=alphaev5-dec-osf4.0e --prefix=/usr/local
--with-extra-inc=/usr/local/include --disable-nls --with-included-gettext
--without-included-string --with-qt-dir=$QTDIR --with-kde-dir=$KDEDIR
-with-frontend=kde
--- configure Thu Sep 21 10:11:13 2000
+++ configure.hack Thu Sep 21 09:53:43 2000
@@ -76,7 +76,7 @@
--with-pspell-lib where the libpspell.a is located"
ac_help="$ac_help
--with-xuse the X Window System"
-ac_default_prefix=${KDEDIR:-/usr/local/kde}
+ac_default_prefix=${KDEDIR}
ac_help="$ac_help
--enable-shared[=PKGS] build shared libraries [default=yes]"
ac_help="$ac_help
@@ -7164,7 +7164,7 @@
if test -z ""; then
-kde_incdirs="/usr/lib/kde/include /usr/local/kde/include /usr/kde/include /usr/include/kde /usr/include /opt/kde/include $x_includes $qt_includes"
+kde_incdirs="/usr/lib/kde/include /usr/kde/include /usr/include/kde /usr/include /opt/kde/include $x_includes $qt_includes"
test -n "$KDEDIR" kde_incdirs="$KDEDIR/include $KDEDIR $kde_incdirs"
kde_incdirs="$ac_kde_includes $kde_incdirs"
@@ -7188,7 +7188,7 @@
So, check this please and use another prefix!" 12; exit 1; }
fi
-kde_libdirs="/usr/lib/kde/lib /usr/local/kde/lib /usr/kde/lib /usr/lib/kde /usr/lib /usr/X11R6/lib /opt/kde/lib /usr/X11R6/kde/lib"
+kde_libdirs="/usr/lib/kde/lib /usr/kde/lib /usr/lib/kde /usr/lib /usr/X11R6/lib /opt/kde/lib /usr/X11R6/kde/lib"
test -n "$KDEDIR" kde_libdirs="$KDEDIR/lib $KDEDIR $kde_libdirs"
kde_libdirs="$ac_kde_libraries $kde_libdirs"
error compiling latest cvs with-frontend=kde
When compiling lyx-devel, cvs sep 21, on a redhat 6.2 system, with qt1x-1.45-3 qt1x-devel-1.45-3[ gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) and doing ./configure --disable-nls --with-frontend=kde --with-qt-dir=/usr/lib/qt-1.45 I get the following error message: /bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/-I../../.. -I../../.. -I./kde -I/usr/lib/qt-1.45/include -I/usr/include/kde -I../../../src/frontends/xforms -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall -Wno-return-type -c FormToc.C g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/ -I../../.. -I../../.. -I./kde -I/usr/lib/qt-1.45/include -I/usr/include/kde -I../../../src/frontends/xforms -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall -Wno-return-type -Wp,-MD,.deps/FormToc.pp -c FormToc.C -o FormToc.o In file included from /usr/lib/qt-1.45/include/qpainter.h:33, from /usr/lib/qt-1.45/include/qdrawutil.h:28, from /usr/lib/qt-1.45/include/qscrollbar.h:30, from /usr/lib/qt-1.45/include/qscrollview.h:28, from /usr/lib/qt-1.45/include/qlistview.h:37, from formtocdialog.h:28, from FormToc.C:20: /usr/lib/qt-1.45/include/qregion.h:74: parse error before `^' /usr/lib/qt-1.45/include/qregion.h:118: duplicate nested type `QRegion' make[4]: *** [FormToc.lo] Error 1 make[4]: Leaving directory `/tmp/lyx-devel/src/frontends/kde' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/tmp/lyx-devel/src/frontends' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/lyx-devel/src' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/tmp/lyx-devel/src' make: *** [all-recursive] Error 1 Edwin
Re: error compiling latest cvs with-frontend=kde
On Thu, 21 Sep 2000, Edwin Leuven wrote: I get the following error message: /bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/-I../../.. -I../../.. -I./kde -I/usr/lib/qt-1.45/include -I/usr/include/kde -I../../../src/frontends/xforms -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall -Wno-return-type -c FormToc.C g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/ -I../../.. -I../../.. -I./kde -I/usr/lib/qt-1.45/include -I/usr/include/kde -I../../../src/frontends/xforms -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall -Wno-return-type -Wp,-MD,.deps/FormToc.pp -c FormToc.C -o FormToc.o In file included from /usr/lib/qt-1.45/include/qpainter.h:33, from /usr/lib/qt-1.45/include/qdrawutil.h:28, from /usr/lib/qt-1.45/include/qscrollbar.h:30, from /usr/lib/qt-1.45/include/qscrollview.h:28, from /usr/lib/qt-1.45/include/qlistview.h:37, from formtocdialog.h:28, from FormToc.C:20: /usr/lib/qt-1.45/include/qregion.h:74: parse error before `^' /usr/lib/qt-1.45/include/qregion.h:118: duplicate nested type `QRegion' make[4]: *** [FormToc.lo] Error 1 make[4]: Leaving directory `/tmp/lyx-devel/src/frontends/kde' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/tmp/lyx-devel/src/frontends' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/lyx-devel/src' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/tmp/lyx-devel/src' make: *** [all-recursive] Error 1 Edwin I have seen this myself. It is to do with Qt breaking by trying to use xor which is a keyword in standard c++. In my opinion this is a broken header used in Qt. For the benefit of the list the relevant section is : #if !(defined(__STRICT_ANSI__) defined(_CC_GNU_)) !defined(_CC_EDG_) !defined(_CC_HP_) !defined(_CC_HP_ACC_) !defined(_CC_USLC_) !defined(_CC_MWERKS_) !defined(xor) QRegion xor( const QRegion ) const; #endif QRegion eor( const QRegion ) const; Does someone want to suggest how this might be worked around ? In my opinion this is Qt being wrong, again. thanks john p.s. Edwin, you may temporarily work around this by commenting out line 74 of /usr/lib/qt-1.45/include/qregion.h by placing // in front of it. Otherwise you can wait till a fix is in place.
Re: small compilation problems
On Wed, 20 Sep 2000, Lior Silberman wrote: 2. src/filedlg.C compiles ok, but during the link phase, I get: filedlg.o: In function `LyXFileDlg::Reread(void)': filedlg.C:245: undefined reference to `GroupCache::find(unsigned int) const I think this is beacuse g++ -g does not expand GroupCache::find inline, and therefore it's missing from the object file. Compiling this file separately with (-g -O) solves the problem. I wonder why this happens, since there is no complaint about UserCache::find. I have the exact same problem. I have to apply a patch to filedlg.C each time. Unfortunately no-one else on the list can see this (Except you ;) thanks john
Re: Making lyx with the kde frontend
On Thu, 21 Sep 2000, Angus Leeming wrote:
When it came to configuring/compiling/linking lyx, again all went fairly
smoothly, but there are some bugs in the configure script which could be
removed.
I have just done :
./configure --with-frontend=kde --with-qt-dir=/usr/lib/qt-1.45/
and got :
checking for Qt... libraries /usr/lib/qt-1.45//lib, headers
/usr/lib/qt-1.45//include
so it seems that is OK at least. Setting QTDIR is also fine. I think what
happened here is that you didn't "rm config.cache" inbetween. Surprisingly
this *is* necessary, even though it doesn't say "cached" on the configure
output, because of :
ac_cv_have_qt=${ac_cv_have_qt='have_qt=yes
ac_qt_includes=/usr/lib/qt-1.45//include
ac_qt_libraries=/usr/lib/qt-1.45//lib'}
in config.cache.
I can't check KDE right now but I'm guessing it's the same. Please can you
try to reproduce after "rm config.cache" ?
It is also possible that your setup is slightly wrong, in which case it
will try the default locations in the order seen in the scripts. Debugging
configure scripts is no fun at all :)
john
--
"EBCDIC - IBM's answer to uncrackable data encryption"
- Vorlon
Re: Making lyx with the kde frontend
* Recreate configure by running autogen.sh
* Run configure through the shell script that I sent before. Also attached to
this mail.
Here I get:
checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib,
headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include
Which is correct, but:
checking for KDE... libraries /usr/local/kde/lib, headers
/usr/users/aleem/OTHERS_CODE/kde-1.1.2/include
checking for kde headers installed... cxx -std strict_ansi -nocleanup -c -ptr
/usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2
-I/usr/users/aleem/OTHERS_CODE/kde-1.1.2/include
-I/usr/users/aleem/OTHERS_CODE/qt-1.44/include -I$(top_srcdir)/src/cheaders
-I/usr/local/include conftest.C
yes
checking for kde libraries installed... configure: error: your system fails
at linking a small KDE application!
Check, if your compiler is installed correctly and if you have used the
same compiler to compile Qt and kdelibs as you did use now
You'll see that it has decided to use the installed kde libraries rather than
the ones I want! Uses the correct header files though!
I think that this nails the problem. Thanks for forcing me to get off my butt
and give you some useful info, rather than just whining about it!
Incidentally, we currently require only the kdecore library, but link in
several other ones also. Will this change as more functionality is handed
over to kde?
Angus
On Thu, 21 Sep 2000, John Levon wrote:
On Thu, 21 Sep 2000, Angus Leeming wrote:
When it came to configuring/compiling/linking lyx, again all went fairly
smoothly, but there are some bugs in the configure script which could be
removed.
I have just done :
./configure --with-frontend=kde --with-qt-dir=/usr/lib/qt-1.45/
and got :
checking for Qt... libraries /usr/lib/qt-1.45//lib, headers
/usr/lib/qt-1.45//include
so it seems that is OK at least. Setting QTDIR is also fine. I think what
happened here is that you didn't "rm config.cache" inbetween. Surprisingly
this *is* necessary, even though it doesn't say "cached" on the configure
output, because of :
ac_cv_have_qt=${ac_cv_have_qt='have_qt=yes
ac_qt_includes=/usr/lib/qt-1.45//include
ac_qt_libraries=/usr/lib/qt-1.45//lib'}
in config.cache.
I can't check KDE right now but I'm guessing it's the same. Please can you
try to reproduce after "rm config.cache" ?
It is also possible that your setup is slightly wrong, in which case it
will try the default locations in the order seen in the scripts. Debugging
configure scripts is no fun at all :)
john
configure-dec
Re: Making lyx with the kde frontend
On Thu, 21 Sep 2000, Angus Leeming wrote: * Recreate configure by running autogen.sh * Run configure through the shell script that I sent before. Also attached to this mail. Here I get: checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib, headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include Which is correct, but: good checking for KDE... libraries /usr/local/kde/lib, headers /usr/users/aleem/OTHERS_CODE/kde-1.1.2/include checking for kde headers installed... cxx -std strict_ansi -nocleanup -c -ptr /usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2 -I/usr/users/aleem/OTHERS_CODE/kde-1.1.2/include -I/usr/users/aleem/OTHERS_CODE/qt-1.44/include -I$(top_srcdir)/src/cheaders -I/usr/local/include conftest.C yes checking for kde libraries installed... configure: error: your system fails at linking a small KDE application! Check, if your compiler is installed correctly and if you have used the same compiler to compile Qt and kdelibs as you did use now You'll see that it has decided to use the installed kde libraries rather than the ones I want! Uses the correct header files though! I am guessing that you do not have a libkdecore.la file in the specified location. Is this correct ? I must admit personally I don't understand the reason we use .la. Maybe this should be changed to libkdecore.so or something. You can check this works by hacking the configure script. Maybe someone with more experience of how the linker works can explain what these .la files are actually used for, and why we require it. Incidentally, we currently require only the kdecore library, but link in several other ones also. Will this change as more functionality is handed over to kde? Angus I don't think this is necessary. It is not that the library is "required", rather that it is used to determine the location of the libraries, hence is more of a "search tag". It is assumed that you have a correctly installed KDE system, if this file can be found. thanks john -- "EBCDIC - IBM's answer to uncrackable data encryption" - Vorlon
Re: Making lyx with the kde frontend
Hi Angus!
It's great to hear about your success! :-)
On Thu, Sep 21, 2000 at 02:20:09PM +0100, Angus Leeming wrote:
checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib,
headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include
[ snip ]
checking for KDE... libraries /usr/local/kde/lib, headers
/usr/users/aleem/OTHERS_CODE/kde-1.1.2/include
Isn't it a futile effort still using qt-1.4x and KDE-1.x for the KLyX
port? Wouldn't it make more sense basing this port right away on a
GPL'ed qt-2.x and the forthcoming KDE-2.x?
Thank you, P. *8^)
--
Paul Seelig [EMAIL PROTECTED] -
African Music Archive - Institute for Ethnology and Africa Studies
Johannes Gutenberg-University - Forum 6 - 55099 Mainz/Germany
--- http://ntama.uni-mainz.de
Re: Making lyx with the kde frontend
On Thu, 21 Sep 2000, Paul Seelig wrote: Hi Angus! It's great to hear about your success! :-) On Thu, Sep 21, 2000 at 02:20:09PM +0100, Angus Leeming wrote: checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib, headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include [ snip ] checking for KDE... libraries /usr/local/kde/lib, headers /usr/users/aleem/OTHERS_CODE/kde-1.1.2/include Isn't it a futile effort still using qt-1.4x and KDE-1.x for the KLyX port? Wouldn't it make more sense basing this port right away on a GPL'ed qt-2.x and the forthcoming KDE-2.x? Thank you, P. *8^) No, both me and Juergen agree on this. KDE2 is not even out yet, although its stability is improving. Look at the two choices like this : 1) we do KDE2 now. for at least six months, practically nobody can use it except the small percentage with a bleeding-edge distribution, or the rare few who install it themselves. for at least four years, there will be KDE 1.x boxes around which are unable to use the KDE version of lyx. This is especially true in university environments, where old boxes can stay fairly unmaintained. And students/researchers are one of the big users of lyx ;) 2) we do KDE1 now, KDE 2 later. KDE lyx will be immediately usable to the vast majority of users. I expect many people to keep KDE1 installations even when KDE2 is installed for other applications that aren't updated. When KDE2 becomes widespread, additionally porting to it will be simpler than the xforms-kde first step. AND we can keep *both* so both KDE1 and KDE2 users can benefit. So I much much prefer the second option. This is all imho of course ! thanks john -- "EBCDIC - IBM's answer to uncrackable data encryption" - Vorlon
Re: Making lyx with the kde frontend
No, I don't think so. The changes that would need to be made to the code base are minimal and well documented. Porting apps from kde-1.1.2 to kde-2.x is (apparently) very easy. Anyway, the guy doing the port (John Levon) is running kde-1.1.2, so really the question is academic. Feel free to contribute if you desire something else!!! ;-P Better to do it this way round too, because kde-1.1.2 is still the stable system. What proportion of kde users are running kde-2? My guess would be 1%. Angus On Thu, 21 Sep 2000, Paul Seelig wrote: Hi Angus! It's great to hear about your success! :-) On Thu, Sep 21, 2000 at 02:20:09PM +0100, Angus Leeming wrote: checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib, headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include [ snip ] checking for KDE... libraries /usr/local/kde/lib, headers /usr/users/aleem/OTHERS_CODE/kde-1.1.2/include Isn't it a futile effort still using qt-1.4x and KDE-1.x for the KLyX port? Wouldn't it make more sense basing this port right away on a GPL'ed qt-2.x and the forthcoming KDE-2.x? Thank you, P. *8^)
Re: Lost math bindings
"Amir" == Amir Karger [EMAIL PROTECTED] writes:
Amir But where would the "open math panel" command go?
At the same place as the TOC popup (so Eit for now).
Amir If we do find places for these commands, I definitely think we
Amir should get rid of the math menu. Because anyone who really wants
Amir one can always add one, but meanwhile it's not like the
Amir particular math commands chose (super/subscript, integral,
Amir fraction) are used *so* much more than lots of other commands
Amir that aren't in the menu.
So, if we get rid of the math menu, should we keep the math bindings
on M-m? I think if we don't, there will be a riot from users, but Lars
disagrees...
Amir Sorry! I meant "\right(" et al. Tried it out in LyX and I get a
Amir red "right" plus a blue (, which isn't what I want.
One of these thing that mathed only half knows about...
JMarc
Re: [f95ts@efd.lth.se] [Lyx-feedback] Feedback from www.lyx.org
Tommy I\'m trying to compile LyX, but I don\'t have Perl on my Tommy system, I guess this is the main problemanyway I thought it Tommy wasn\'t necessary to have Perl in order to comile the sourece Tommy configure works fine, but when make enters relyx it doesn\'t Tommy find a Makefile, wich is true as there isn\'t a Makefile. I\'ve Tommy tried with \"export PERL=3D/bin/ls\" but didn\'t work either. You shouldn't need to have perl. What exact error messages do you get? What version of LyX are you trying to compile? JMarc
Re: Making lyx with the kde frontend
You'll see that it has decided to use the installed kde libraries rather than the ones I want! Uses the correct header files though! I am guessing that you do not have a libkdecore.la file in the specified location. Is this correct ? I must admit personally I don't understand the reason we use .la. Maybe this should be changed to libkdecore.so or something. You can check this works by hacking the configure script. Maybe someone with more experience of how the linker works can explain what these .la files are actually used for, and why we require it. The linker doesn't require the .la files at all. This is something to do with libtool. However, the point is well made, I have only the statically linked .a files in kde-1.1.2/lib. I had a separte and now resolved problem with shared libraries, and so made a separete kde-1.1.2/shlib directory for them. It's this directory that also contains the .la files. Anyway, I have done exactly as you suggest and put relevant .la files in kde-1.1.2/lib I changed my configure script to point to the includes and libraries explicitly, rather than to the base qt and kde dirs. QTDIR and KDEDIR are now undefined. Everything configues perfectly, both when using the static libraries in qt-1.44/lib and kde-1.1.2/lib and when using the shared libraries in qt-1.44/shlib and kde-1.1.2/shlib Everything makes perfectly too, with no tweaking of src/Makefile when I link in the shared libraries. When linking in the static libraries, however, I must change things round to -lkdecore -lqt Note that when compiling with the static libraries, I must also link in -lXext. I obviously wasn't paying enough attention when making the kde shared libraries and allowed them to link this in themselves. Many thanks for all your help. Angus
Re: Lost math bindings
On 21 Sep 2000, Jean-Marc Lasgouttes wrote:
So, if we get rid of the math menu, should we keep the math bindings
on M-m? I think if we don't, there will be a riot from users, but Lars
disagrees...
Yes, LyX had the hability to give users the choice to use the interface
they liked the more. Is really necessary to take away that?
Amir Sorry! I meant "\right(" et al. Tried it out in LyX and I get a
Amir red "right" plus a blue (, which isn't what I want.
One of these thing that mathed only half knows about...
Is the produced latex right? Why don't you use M-m C ?
Alejandro
(Not very active LyX developer by now but still an user)
Re: Making lyx with the kde frontend
On Thu, 21 Sep 2000, Angus Leeming wrote: The linker doesn't require the .la files at all. This is something to do with libtool. OK, so is it correct to insist that libkdecore.la exists ? Can anyone comment ? Everything makes perfectly too, with no tweaking of src/Makefile when I link in the shared libraries. When linking in the static libraries, however, I must change things round to -lkdecore -lqt ok. I do remember something about how this works in that you should always leave things as late in the order as you can. I imagine it's trivial to fix the Makefile.in for this order ? Many thanks for all your help. Angus glad to help thanks john -- "EBCDIC - IBM's answer to uncrackable data encryption" - Vorlon
Re: Making lyx with the kde frontend
On Thu, Sep 21, 2000 at 03:06:52PM +0100, John Levon wrote:
On Thu, 21 Sep 2000, Paul Seelig wrote:
Isn't it a futile effort still using qt-1.4x and KDE-1.x for the KLyX
port? Wouldn't it make more sense basing this port right away on a
GPL'ed qt-2.x and the forthcoming KDE-2.x?
No, both me and Juergen agree on this. KDE2 is not even out yet, although
its stability is improving. Look at the two choices like this :
[ snip ]
Too bad, this unfortunately means no qt-1.4x-based official KLyX
package in Debian (my favourite distribution) until it has been ported
using KDE-2.x which is based on the recently GPL'ed qt-2.x. Oh well,
that's live. :-(
I just hope that the GTK/GNOME frontend becomes a worthwhile compile
ASAP. I'd really love to get rid of having to use LyX via the XForms
frontend once and for all... ;-)
Thanks, P. *8^)
--
Paul Seelig [EMAIL PROTECTED] -
African Music Archive - Institute for Ethnology and Africa Studies
Johannes Gutenberg-University - Forum 6 - 55099 Mainz/Germany
--- http://ntama.uni-mainz.de
Re: Making lyx with the kde frontend
On Thu, 21 Sep 2000, Paul Seelig wrote: I just hope that the GTK/GNOME frontend becomes a worthwhile compile ASAP. afaik the gnome frontend is currently more advanced than the KDE one ! I'd really love to get rid of having to use LyX via the XForms frontend once and for all... ;-) Thanks, P. *8^) me too :) john -- "EBCDIC - IBM's answer to uncrackable data encryption" - Vorlon
small problem in lyxstring constructor
While running purify on lyx, I find plenty of uninitialized memory
read coming from lyxstring constructor
lyxstring::lyxstring(value_type const * s, size_type n)
The problem is that the constructor uses at some place min(n, strlen(s))
although s may not be null terminated. I propose to rewrite the
constructor as follows:
lyxstring::lyxstring(value_type const * s, size_type n)
{
Assert(s n npos); // STD!
static Srep empty_rep(0, "");
if (*s n) { // s is not empty string and n 0
size_type l = 0;
while (l n s[l])
l++;
rep = new Srep(l, s);
// rep = new Srep(min(strlen(s),n), s);
} else {
++empty_rep.ref;
rep = empty_rep;
}
}
Lars, before changing this somewhat sensitive code, could you comment
on what is the right fix?
JMarc
inset questions
I see that the following files in src/insets still #include FORMS_H_LOCATION: figinset.C, form_graphics.C, form_graphics.h, insetbib.C, inseterror.h, insetexternal.C, insetinclude.C, insetinfo.h Are form_graphics.[Ch] to be made redundant by Baruch's efforts in this direction? What about figinset.[Ch]? This leaves the 5 inset files and associated classes. I was going to have a go at making InsetInfo GUI-independent, but have vague notions that people were suggesting that it too should go? (I haven't been paying much attention of late) Is this so or should I do my worst on it? Angus
Re: small compilation problems
On Thu, 21 Sep 2000, Allan Rae wrote: On Wed, 20 Sep 2000, Lior Silberman wrote: 1. sigc++/thread.h doesn't include the declaration for struct timespec, Did you report this to libsigc++? I notice it's been fixed in their repository so I'll do up a new sigc++ mini-dist. Allan. (ARRae) Allan Thanks! I didn't know sigc++ wasn't part of the LyX project, so I didn't report this to anyone before yesterday. Lior.
Re: Lost math bindings
Alejandro Aguilar Sierra wrote:
On 21 Sep 2000, Jean-Marc Lasgouttes wrote:
So, if we get rid of the math menu, should we keep the math bindings
on M-m? I think if we don't, there will be a riot from users, but Lars
disagrees...
Yes, LyX had the hability to give users the choice to use the interface
they liked the more. Is really necessary to take away that?
Amir Sorry! I meant "\right(" et al. Tried it out in LyX and I get a
Amir red "right" plus a blue (, which isn't what I want.
One of these thing that mathed only half knows about...
Is the produced latex right? Why don't you use M-m C ?
It doesn't work anymore :( I assume you meant M-m (
Alejandro
(Not very active LyX developer by now but still an user)
For the menu bindings I would prefer M-Sm and M-m for math.
Things are M-essed up now.
Garst
Re: Lost math bindings
On Thu, 21 Sep 2000, Garst R. Reese wrote: Is the produced latex right? Why don't you use M-m C ? It doesn't work anymore :( I assume you meant M-m ( Yes, of course. I have not followed this thread but it seems that the philosofy has changed. Users won't have anymore the flexiblity to change the interface how ever they like. Unless there are very good reasons for that, this is a shame. Alejandro
patch
Attached is a patch rendering InsetError GUI-independent, together with an
xforms implementation of the associated dialog.
I've implemented the FormError dialog by defining a new base class, FormBase.
I think that this could be the base class for all the xforms dialogs.
Thoughts? Allan?
I've also modified the kde Makefile, Dialogs.C to add the new xforms dialog.
I have not done this to the gnome frontend, because I can't (yet?) test it
out.
Incidentally, I notice that kde/Dialogs.C and xforms/Dialogs.C differ.
Shouldn't they be identical? See below.
Lars, I have finally got round to installing ssh. How about that cvs access
now, at least so that I can "cvs add"
Angus
diff -u frontends/kde/Dialogs.C frontends/xforms/Dialogs.C
--- frontends/kde/Dialogs.C Thu Sep 21 19:37:15 2000
+++ frontends/xforms/Dialogs.C Thu Sep 21 19:21:43 2000
@@ -19,6 +19,9 @@
#pragma implementation
#endif
+// temporary till ported
+extern void ShowCredits();
+
Dialogs::Dialogs(LyXView * lv)
{
@@ -34,6 +37,8 @@
dialogs_.push_back(new FormTabular(lv, this));
dialogs_.push_back(new FormToc(lv, this));
dialogs_.push_back(new FormUrl(lv, this));
+
+ showCredits.connect(slot(ShowCredits));
// reduce the number of connections needed in
// dialogs by a simple connection here.
patch21Sep2000.tar.bz2
Re: inset questions
On Thu, 21 Sep 2000, Angus Leeming wrote: I see that the following files in src/insets still #include FORMS_H_LOCATION: figinset.C, form_graphics.C, form_graphics.h, insetbib.C, inseterror.h, insetexternal.C, insetinclude.C, insetinfo.h Are form_graphics.[Ch] to be made redundant by Baruch's efforts in this direction? What about figinset.[Ch]? The form_graphics.[Ch] in the insets/ directory are obsoleted together with the figinset.[Ch], however since my FormGraphics is still not up to par with the figinset (no inline viewing) it probably should not be removed for now. I'll be back to my development machine tommorow and will try to finish the parts that still need work. I'll be replacing my devel machine and be back to work on FormGraphics. Baruch
Re: cvs --with-pspell no go
On Tue, 19 Sep 2000, Juergen Vigna wrote: On 19-Sep-2000 Kevin Atkinson wrote: Um in a previous email: Date: Mon, 4 Sep 2000 06:26:38 -0400 (EDT) From: Kevin Atkinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Two letter ISO 639 language code? In order to spell checker in other languages in Pspell the two letter ISO 639 language code is needed. Is there a way to get this? Or do I need to create a lookup table from the ispell language name to the code? I also need the country code in some cases, like for using the Canadian dictionary. Ok we already decided to add this language_country code so that you can use it later. Um where. How do I use it? I also need the country code for languages which you have down such as "american" may I suggest you use the standard syntax which will be language code_country code for example american will be "en_US". I also need a way know the encoding that LyX will be sending the TeX in. The current known encodings are ``utf-8'', ``iso8859-*'', ``koi8-r'', ``viscii'', ``cp1252'', ``machine unsigned 16'', ``machine unsigned 32''. Case does not matter. Kevin Atkinson kevina at users sourceforge net http://metalab.unc.edu/kevina/
Re: inset questions
On Thu, 21 Sep 2000, Angus Leeming wrote: I see that the following files in src/insets still #include FORMS_H_LOCATION: figinset.C, form_graphics.C, form_graphics.h, insetbib.C, inseterror.h, insetexternal.C, insetinclude.C, insetinfo.h Are form_graphics.[Ch] to be made redundant by Baruch's efforts in this direction? What about figinset.[Ch]? This leaves the 5 inset files and associated classes. I was going to have a go at making InsetInfo GUI-independent, but have vague notions that people were suggesting that it too should go? (I haven't been paying much attention of late) Is this so or should I do my worst on it? Info will become a collapsible inset and so it won't be needing a dialog in future. It should be fairly easy to implement (give it a better name at the same time like InsetProofread or something since it's meant for sticking editting notes into and should be possible to block export to certain formats (eg. ascii text). You work on one of the others, although InsetExternal and InsetGraphics are likely to be merged at some point (I think you were away for those threads) so you might just skip external for now. There's always fine-tuning to do if you need some work to do ;-) Allan. (ARRae)
Making lyx with the kde frontend
Ok, I'm feeling pretty proud of myself. I've compiled and linked lyx with
the kde frontend. This has meant compiling the kde-1.1.2 libraries with DEC
cxx; straightforward, but tedious with all those "using std::xxx" and extern
"C" calls I've come to know and love ;-)
Incidentally, Jean-Marc, if you are interested but don't want to go through
the pain, I'll happily ftp the qt/kde libs.
When it came to configuring/compiling/linking lyx, again all went fairly
smoothly, but there are some bugs in the configure script which could be
removed.
The script with which I configured lyx is at the bottom of this letter.
You'll see that I specify explicitly where to find the cxx-compiled qt and
kde libs and header files. I think that configure should respect these. I
have a working version, compiled with gcc and retrieved from the kde ftp
site, of qt/kde installed on my machine in /usr/local/qt and /usr/local/kde
that I didn't want (couldn't) use. To ensure this was so, I had to hack the
configure script. Diff file is attached.
Finally, the src/Makefile defines the qt and kdelibraries as:
-lqt -lkdecore
This results in lots of "can't find symbol" errors. On the DEC the order of
these library declarations is important. They should be
-lkdecore -lqt
Hope that these comments are of some use.
Angus
#!/bin/sh
QTDIR=/usr/users/aleem/OTHERS_CODE/qt-1.44
export QTDIR
KDEDIR=/usr/users/aleem/OTHERS_CODE/kde-1.1.2
export KDEDIR
LYXDIR=/usr/users/aleem/OTHERS_CODE/lyx/devel
export LYXDIR
CC=deccc
export
CFLAGS=-O2
export CFLAGS
CXX=deccxx
export CXX
CXXFLAGS="-ptr $LYXDIR/lyx_cxx_repository -O2"
export CXXFLAGS
./configure --host=alphaev5-dec-osf4.0e --prefix=/usr/local
--with-extra-inc=/usr/local/include --disable-nls --with-included-gettext
--without-included-string --with-qt-dir=$QTDIR --with-kde-dir=$KDEDIR
-with-frontend=kde
--- configure Thu Sep 21 10:11:13 2000
+++ configure.hack Thu Sep 21 09:53:43 2000
@@ -76,7 +76,7 @@
--with-pspell-lib where the libpspell.a is located"
ac_help="$ac_help
--with-xuse the X Window System"
-ac_default_prefix=${KDEDIR:-/usr/local/kde}
+ac_default_prefix=${KDEDIR}
ac_help="$ac_help
--enable-shared[=PKGS] build shared libraries [default=yes]"
ac_help="$ac_help
@@ -7164,7 +7164,7 @@
if test -z ""; then
-kde_incdirs="/usr/lib/kde/include /usr/local/kde/include /usr/kde/include /usr/include/kde /usr/include /opt/kde/include $x_includes $qt_includes"
+kde_incdirs="/usr/lib/kde/include /usr/kde/include /usr/include/kde /usr/include /opt/kde/include $x_includes $qt_includes"
test -n "$KDEDIR" && kde_incdirs="$KDEDIR/include $KDEDIR $kde_incdirs"
kde_incdirs="$ac_kde_includes $kde_incdirs"
@@ -7188,7 +7188,7 @@
So, check this please and use another prefix!" 1>&2; exit 1; }
fi
-kde_libdirs="/usr/lib/kde/lib /usr/local/kde/lib /usr/kde/lib /usr/lib/kde /usr/lib /usr/X11R6/lib /opt/kde/lib /usr/X11R6/kde/lib"
+kde_libdirs="/usr/lib/kde/lib /usr/kde/lib /usr/lib/kde /usr/lib /usr/X11R6/lib /opt/kde/lib /usr/X11R6/kde/lib"
test -n "$KDEDIR" && kde_libdirs="$KDEDIR/lib $KDEDIR $kde_libdirs"
kde_libdirs="$ac_kde_libraries $kde_libdirs"
error compiling latest cvs with-frontend=kde
When compiling lyx-devel, cvs sep 21, on a redhat 6.2 system, with qt1x-1.45-3 qt1x-devel-1.45-3[ gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) and doing ./configure --disable-nls --with-frontend=kde --with-qt-dir=/usr/lib/qt-1.45 I get the following error message: /bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/-I../../.. -I../../.. -I./kde -I/usr/lib/qt-1.45/include -I/usr/include/kde -I../../../src/frontends/xforms -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall -Wno-return-type -c FormToc.C g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/ -I../../.. -I../../.. -I./kde -I/usr/lib/qt-1.45/include -I/usr/include/kde -I../../../src/frontends/xforms -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall -Wno-return-type -Wp,-MD,.deps/FormToc.pp -c FormToc.C -o FormToc.o In file included from /usr/lib/qt-1.45/include/qpainter.h:33, from /usr/lib/qt-1.45/include/qdrawutil.h:28, from /usr/lib/qt-1.45/include/qscrollbar.h:30, from /usr/lib/qt-1.45/include/qscrollview.h:28, from /usr/lib/qt-1.45/include/qlistview.h:37, from formtocdialog.h:28, from FormToc.C:20: /usr/lib/qt-1.45/include/qregion.h:74: parse error before `^' /usr/lib/qt-1.45/include/qregion.h:118: duplicate nested type `QRegion' make[4]: *** [FormToc.lo] Error 1 make[4]: Leaving directory `/tmp/lyx-devel/src/frontends/kde' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/tmp/lyx-devel/src/frontends' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/lyx-devel/src' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/tmp/lyx-devel/src' make: *** [all-recursive] Error 1 Edwin
Re: error compiling latest cvs with-frontend=kde
On Thu, 21 Sep 2000, Edwin Leuven wrote: > I get the following error message: > /bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../src >-I../../../src/ -I../../../src/frontends/-I../../.. -I../../.. -I./kde >-I/usr/lib/qt-1.45/include -I/usr/include/kde -I../../../src/frontends/xforms >-isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall >-Wno-return-type -c FormToc.C > g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/ >-I../../.. -I../../.. -I./kde -I/usr/lib/qt-1.45/include -I/usr/include/kde >-I../../../src/frontends/xforms -isystem /usr/X11R6/include -g -O -fno-rtti >-fno-exceptions -ansi -W -Wall -Wno-return-type -Wp,-MD,.deps/FormToc.pp -c FormToc.C >-o FormToc.o > In file included from /usr/lib/qt-1.45/include/qpainter.h:33, > from /usr/lib/qt-1.45/include/qdrawutil.h:28, > from /usr/lib/qt-1.45/include/qscrollbar.h:30, > from /usr/lib/qt-1.45/include/qscrollview.h:28, > from /usr/lib/qt-1.45/include/qlistview.h:37, > from formtocdialog.h:28, > from FormToc.C:20: > /usr/lib/qt-1.45/include/qregion.h:74: parse error before `^' > /usr/lib/qt-1.45/include/qregion.h:118: duplicate nested type `QRegion' > make[4]: *** [FormToc.lo] Error 1 > make[4]: Leaving directory `/tmp/lyx-devel/src/frontends/kde' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/tmp/lyx-devel/src/frontends' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/tmp/lyx-devel/src' > make[1]: *** [all-recursive-am] Error 2 > make[1]: Leaving directory `/tmp/lyx-devel/src' > make: *** [all-recursive] Error 1 > > > Edwin > I have seen this myself. It is to do with Qt breaking by trying to use xor which is a keyword in standard c++. In my opinion this is a broken header used in Qt. For the benefit of the list the relevant section is : #if !(defined(__STRICT_ANSI__) && defined(_CC_GNU_)) && !defined(_CC_EDG_) && !defined(_CC_HP_) && !defined(_CC_HP_ACC_) && !defined(_CC_USLC_) && !defined(_CC_MWERKS_) && !defined(xor) QRegion xor( const QRegion & ) const; #endif QRegion eor( const QRegion & ) const; Does someone want to suggest how this might be worked around ? In my opinion this is Qt being wrong, again. thanks john p.s. Edwin, you may temporarily work around this by commenting out line 74 of /usr/lib/qt-1.45/include/qregion.h by placing // in front of it. Otherwise you can wait till a fix is in place.
Re: small compilation problems
On Wed, 20 Sep 2000, Lior Silberman wrote: > 2. src/filedlg.C compiles ok, but during the link phase, I get: > filedlg.o: In function `LyXFileDlg::Reread(void)': > filedlg.C:245: undefined reference to `GroupCache::find(unsigned int) const > > I think this is beacuse g++ -g does not expand GroupCache::find inline, > and therefore it's missing from the object file. Compiling this file > separately with (-g -O) solves the problem. I wonder why this happens, > since there is no complaint about UserCache::find. > I have the exact same problem. I have to apply a patch to filedlg.C each time. Unfortunately no-one else on the list can see this (Except you ;) thanks john
Re: Making lyx with the kde frontend
On Thu, 21 Sep 2000, Angus Leeming wrote:
> When it came to configuring/compiling/linking lyx, again all went fairly
> smoothly, but there are some bugs in the configure script which could be
> removed.
>
I have just done :
./configure --with-frontend=kde --with-qt-dir=/usr/lib/qt-1.45/
and got :
checking for Qt... libraries /usr/lib/qt-1.45//lib, headers
/usr/lib/qt-1.45//include
so it seems that is OK at least. Setting QTDIR is also fine. I think what
happened here is that you didn't "rm config.cache" inbetween. Surprisingly
this *is* necessary, even though it doesn't say "cached" on the configure
output, because of :
ac_cv_have_qt=${ac_cv_have_qt='have_qt=yes
ac_qt_includes=/usr/lib/qt-1.45//include
ac_qt_libraries=/usr/lib/qt-1.45//lib'}
in config.cache.
I can't check KDE right now but I'm guessing it's the same. Please can you
try to reproduce after "rm config.cache" ?
It is also possible that your setup is slightly wrong, in which case it
will try the default locations in the order seen in the scripts. Debugging
configure scripts is no fun at all :)
john
--
"EBCDIC - IBM's answer to uncrackable data encryption"
- Vorlon
Re: Making lyx with the kde frontend
* Recreate configure by running autogen.sh
* Run configure through the shell script that I sent before. Also attached to
this mail.
Here I get:
checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib,
headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include
Which is correct, but:
checking for KDE... libraries /usr/local/kde/lib, headers
/usr/users/aleem/OTHERS_CODE/kde-1.1.2/include
checking for kde headers installed... cxx -std strict_ansi -nocleanup -c -ptr
/usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2
-I/usr/users/aleem/OTHERS_CODE/kde-1.1.2/include
-I/usr/users/aleem/OTHERS_CODE/qt-1.44/include -I$(top_srcdir)/src/cheaders
-I/usr/local/include conftest.C
yes
checking for kde libraries installed... configure: error: your system fails
at linking a small KDE application!
Check, if your compiler is installed correctly and if you have used the
same compiler to compile Qt and kdelibs as you did use now
You'll see that it has decided to use the installed kde libraries rather than
the ones I want! Uses the correct header files though!
I think that this nails the problem. Thanks for forcing me to get off my butt
and give you some useful info, rather than just whining about it!
Incidentally, we currently require only the kdecore library, but link in
several other ones also. Will this change as more functionality is handed
over to kde?
Angus
On Thu, 21 Sep 2000, John Levon wrote:
> On Thu, 21 Sep 2000, Angus Leeming wrote:
> > When it came to configuring/compiling/linking lyx, again all went fairly
> > smoothly, but there are some bugs in the configure script which could be
> > removed.
>
> I have just done :
>
> ./configure --with-frontend=kde --with-qt-dir=/usr/lib/qt-1.45/
>
> and got :
>
> checking for Qt... libraries /usr/lib/qt-1.45//lib, headers
> /usr/lib/qt-1.45//include
>
> so it seems that is OK at least. Setting QTDIR is also fine. I think what
> happened here is that you didn't "rm config.cache" inbetween. Surprisingly
> this *is* necessary, even though it doesn't say "cached" on the configure
> output, because of :
>
> ac_cv_have_qt=${ac_cv_have_qt='have_qt=yes
> ac_qt_includes=/usr/lib/qt-1.45//include
> ac_qt_libraries=/usr/lib/qt-1.45//lib'}
>
> in config.cache.
>
> I can't check KDE right now but I'm guessing it's the same. Please can you
> try to reproduce after "rm config.cache" ?
>
> It is also possible that your setup is slightly wrong, in which case it
> will try the default locations in the order seen in the scripts. Debugging
> configure scripts is no fun at all :)
>
> john
configure-dec
Re: Making lyx with the kde frontend
On Thu, 21 Sep 2000, Angus Leeming wrote: > * Recreate configure by running autogen.sh > * Run configure through the shell script that I sent before. Also attached to > this mail. > > Here I get: > checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib, > headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include > > Which is correct, but: > good > checking for KDE... libraries /usr/local/kde/lib, headers > /usr/users/aleem/OTHERS_CODE/kde-1.1.2/include > checking for kde headers installed... cxx -std strict_ansi -nocleanup -c -ptr > /usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2 > -I/usr/users/aleem/OTHERS_CODE/kde-1.1.2/include > -I/usr/users/aleem/OTHERS_CODE/qt-1.44/include -I$(top_srcdir)/src/cheaders > -I/usr/local/include conftest.C > yes > checking for kde libraries installed... configure: error: your system fails > at linking a small KDE application! > Check, if your compiler is installed correctly and if you have used the > same compiler to compile Qt and kdelibs as you did use now > > You'll see that it has decided to use the installed kde libraries rather than > the ones I want! Uses the correct header files though! > I am guessing that you do not have a libkdecore.la file in the specified location. Is this correct ? I must admit personally I don't understand the reason we use .la. Maybe this should be changed to libkdecore.so or something. You can check this works by hacking the configure script. Maybe someone with more experience of how the linker works can explain what these .la files are actually used for, and why we require it. > > Incidentally, we currently require only the kdecore library, but link in > several other ones also. Will this change as more functionality is handed > over to kde? > Angus > I don't think this is necessary. It is not that the library is "required", rather that it is used to determine the location of the libraries, hence is more of a "search tag". It is assumed that you have a correctly installed KDE system, if this file can be found. thanks john -- "EBCDIC - IBM's answer to uncrackable data encryption" - Vorlon
Re: Making lyx with the kde frontend
Hi Angus!
It's great to hear about your success! :-)
On Thu, Sep 21, 2000 at 02:20:09PM +0100, Angus Leeming wrote:
> checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib,
> headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include
[ snip ]
> checking for KDE... libraries /usr/local/kde/lib, headers
> /usr/users/aleem/OTHERS_CODE/kde-1.1.2/include
>
Isn't it a futile effort still using qt-1.4x and KDE-1.x for the KLyX
port? Wouldn't it make more sense basing this port right away on a
GPL'ed qt-2.x and the forthcoming KDE-2.x?
Thank you, P. *8^)
--
Paul Seelig <[EMAIL PROTECTED]> -
African Music Archive - Institute for Ethnology and Africa Studies
Johannes Gutenberg-University - Forum 6 - 55099 Mainz/Germany
--- http://ntama.uni-mainz.de
Re: Making lyx with the kde frontend
On Thu, 21 Sep 2000, Paul Seelig wrote: > Hi Angus! > > It's great to hear about your success! :-) > > On Thu, Sep 21, 2000 at 02:20:09PM +0100, Angus Leeming wrote: > > checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib, > > headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include > [ snip ] > > checking for KDE... libraries /usr/local/kde/lib, headers > > /usr/users/aleem/OTHERS_CODE/kde-1.1.2/include > > > Isn't it a futile effort still using qt-1.4x and KDE-1.x for the KLyX > port? Wouldn't it make more sense basing this port right away on a > GPL'ed qt-2.x and the forthcoming KDE-2.x? > > Thank you, P. *8^) > No, both me and Juergen agree on this. KDE2 is not even out yet, although its stability is improving. Look at the two choices like this : 1) we do KDE2 now. for at least six months, practically nobody can use it except the small percentage with a bleeding-edge distribution, or the rare few who install it themselves. for at least four years, there will be KDE 1.x boxes around which are unable to use the KDE version of lyx. This is especially true in university environments, where old boxes can stay fairly unmaintained. And students/researchers are one of the big users of lyx ;) 2) we do KDE1 now, KDE 2 later. KDE lyx will be immediately usable to the vast majority of users. I expect many people to keep KDE1 installations even when KDE2 is installed for other applications that aren't updated. When KDE2 becomes widespread, additionally porting to it will be simpler than the xforms->kde first step. AND we can keep *both* so both KDE1 and KDE2 users can benefit. So I much much prefer the second option. This is all imho of course ! thanks john -- "EBCDIC - IBM's answer to uncrackable data encryption" - Vorlon
Re: Making lyx with the kde frontend
No, I don't think so. The changes that would need to be made to the code base are minimal and well documented. Porting apps from kde-1.1.2 to kde-2.x is (apparently) very easy. Anyway, the guy doing the port (John Levon) is running kde-1.1.2, so really the question is academic. Feel free to contribute if you desire something else!!! ;-P Better to do it this way round too, because kde-1.1.2 is still the stable system. What proportion of kde users are running kde-2? My guess would be <1%. Angus On Thu, 21 Sep 2000, Paul Seelig wrote: > Hi Angus! > > It's great to hear about your success! :-) > > On Thu, Sep 21, 2000 at 02:20:09PM +0100, Angus Leeming wrote: > > checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib, > > headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include > > [ snip ] > > > checking for KDE... libraries /usr/local/kde/lib, headers > > /usr/users/aleem/OTHERS_CODE/kde-1.1.2/include > > Isn't it a futile effort still using qt-1.4x and KDE-1.x for the KLyX > port? Wouldn't it make more sense basing this port right away on a > GPL'ed qt-2.x and the forthcoming KDE-2.x? > > Thank you, P. *8^)
Re: Lost math bindings
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes:
Amir> But where would the "open math panel" command go?
At the same place as the TOC popup (so Eit for now).
Amir> If we do find places for these commands, I definitely think we
Amir> should get rid of the math menu. Because anyone who really wants
Amir> one can always add one, but meanwhile it's not like the
Amir> particular math commands chose (super/subscript, integral,
Amir> fraction) are used *so* much more than lots of other commands
Amir> that aren't in the menu.
So, if we get rid of the math menu, should we keep the math bindings
on M-m? I think if we don't, there will be a riot from users, but Lars
disagrees...
Amir> Sorry! I meant "\right(" et al. Tried it out in LyX and I get a
Amir> red "right" plus a blue (, which isn't what I want.
One of these thing that mathed only half knows about...
JMarc
Re: [f95ts@efd.lth.se] [Lyx-feedback] Feedback from www.lyx.org
Tommy> I\'m trying to compile LyX, but I don\'t have Perl on my Tommy> system, I guess this is the main problemanyway I thought it Tommy> wasn\'t necessary to have Perl in order to comile the sourece Tommy> configure works fine, but when make enters relyx it doesn\'t Tommy> find a Makefile, wich is true as there isn\'t a Makefile. I\'ve Tommy> tried with \"export PERL=3D/bin/ls\" but didn\'t work either. You shouldn't need to have perl. What exact error messages do you get? What version of LyX are you trying to compile? JMarc
Re: Making lyx with the kde frontend
> > You'll see that it has decided to use the installed kde libraries rather > > than the ones I want! Uses the correct header files though! > > I am guessing that you do not have a libkdecore.la file in the specified > location. Is this correct ? I must admit personally I don't understand the > reason we use .la. Maybe this should be changed to libkdecore.so or > something. You can check this works by hacking the configure script. > > Maybe someone with more experience of how the linker works can explain > what these .la files are actually used for, and why we require it. The linker doesn't require the .la files at all. This is something to do with libtool. However, the point is well made, I have only the statically linked .a files in kde-1.1.2/lib. I had a separte and now resolved problem with shared libraries, and so made a separete kde-1.1.2/shlib directory for them. It's this directory that also contains the .la files. Anyway, I have done exactly as you suggest and put relevant .la files in kde-1.1.2/lib I changed my configure script to point to the includes and libraries explicitly, rather than to the base qt and kde dirs. QTDIR and KDEDIR are now undefined. Everything configues perfectly, both when using the static libraries in qt-1.44/lib and kde-1.1.2/lib and when using the shared libraries in qt-1.44/shlib and kde-1.1.2/shlib Everything makes perfectly too, with no tweaking of src/Makefile when I link in the shared libraries. When linking in the static libraries, however, I must change things round to -lkdecore -lqt Note that when compiling with the static libraries, I must also link in -lXext. I obviously wasn't paying enough attention when making the kde shared libraries and allowed them to link this in themselves. Many thanks for all your help. Angus
Re: Lost math bindings
On 21 Sep 2000, Jean-Marc Lasgouttes wrote:
> So, if we get rid of the math menu, should we keep the math bindings
> on M-m? I think if we don't, there will be a riot from users, but Lars
> disagrees...
Yes, LyX had the hability to give users the choice to use the interface
they liked the more. Is really necessary to take away that?
> Amir> Sorry! I meant "\right(" et al. Tried it out in LyX and I get a
> Amir> red "right" plus a blue (, which isn't what I want.
>
> One of these thing that mathed only half knows about...
Is the produced latex right? Why don't you use M-m C ?
Alejandro
(Not very active LyX developer by now but still an user)
Re: Making lyx with the kde frontend
On Thu, 21 Sep 2000, Angus Leeming wrote: > The linker doesn't require the .la files at all. This is something to do with > libtool. OK, so is it correct to insist that libkdecore.la exists ? Can anyone comment ? > Everything makes perfectly too, with no tweaking of src/Makefile when I link > in the shared libraries. When linking in the static libraries, however, I > must change things round to > -lkdecore -lqt > ok. I do remember something about how this works in that you should always leave things as late in the order as you can. I imagine it's trivial to fix the Makefile.in for this order ? > > Many thanks for all your help. > Angus > glad to help thanks john -- "EBCDIC - IBM's answer to uncrackable data encryption" - Vorlon
Re: Making lyx with the kde frontend
On Thu, Sep 21, 2000 at 03:06:52PM +0100, John Levon wrote:
> On Thu, 21 Sep 2000, Paul Seelig wrote:
>
> > Isn't it a futile effort still using qt-1.4x and KDE-1.x for the KLyX
> > port? Wouldn't it make more sense basing this port right away on a
> > GPL'ed qt-2.x and the forthcoming KDE-2.x?
>
> No, both me and Juergen agree on this. KDE2 is not even out yet, although
> its stability is improving. Look at the two choices like this :
[ snip ]
Too bad, this unfortunately means no qt-1.4x-based official KLyX
package in Debian (my favourite distribution) until it has been ported
using KDE-2.x which is based on the recently GPL'ed qt-2.x. Oh well,
that's live. :-(
I just hope that the GTK/GNOME frontend becomes a worthwhile compile
ASAP. I'd really love to get rid of having to use LyX via the XForms
frontend once and for all... ;-)
Thanks, P. *8^)
--
Paul Seelig <[EMAIL PROTECTED]> -
African Music Archive - Institute for Ethnology and Africa Studies
Johannes Gutenberg-University - Forum 6 - 55099 Mainz/Germany
--- http://ntama.uni-mainz.de
Re: Making lyx with the kde frontend
On Thu, 21 Sep 2000, Paul Seelig wrote: > I just hope that the GTK/GNOME frontend becomes a worthwhile compile > ASAP. afaik the gnome frontend is currently more advanced than the KDE one ! > I'd really love to get rid of having to use LyX via the XForms > frontend once and for all... ;-) >Thanks, P. *8^) > me too :) john -- "EBCDIC - IBM's answer to uncrackable data encryption" - Vorlon
small problem in lyxstring constructor
While running purify on lyx, I find plenty of uninitialized memory
read coming from lyxstring constructor
lyxstring::lyxstring(value_type const * s, size_type n)
The problem is that the constructor uses at some place min(n, strlen(s))
although s may not be null terminated. I propose to rewrite the
constructor as follows:
lyxstring::lyxstring(value_type const * s, size_type n)
{
Assert(s && n < npos); // STD!
static Srep empty_rep(0, "");
if (*s && n) { // s is not empty string and n > 0
size_type l = 0;
while (l < n && s[l])
l++;
rep = new Srep(l, s);
// rep = new Srep(min(strlen(s),n), s);
} else {
++empty_rep.ref;
rep = _rep;
}
}
Lars, before changing this somewhat sensitive code, could you comment
on what is the right fix?
JMarc
inset questions
I see that the following files in src/insets still #include FORMS_H_LOCATION: figinset.C, form_graphics.C, form_graphics.h, insetbib.C, inseterror.h, insetexternal.C, insetinclude.C, insetinfo.h Are form_graphics.[Ch] to be made redundant by Baruch's efforts in this direction? What about figinset.[Ch]? This leaves the 5 inset files and associated classes. I was going to have a go at making InsetInfo GUI-independent, but have vague notions that people were suggesting that it too should go? (I haven't been paying much attention of late) Is this so or should I do my worst on it? Angus
Re: small compilation problems
On Thu, 21 Sep 2000, Allan Rae wrote: > On Wed, 20 Sep 2000, Lior Silberman wrote: > > > 1. sigc++/thread.h doesn't include the declaration for struct timespec, > > Did you report this to libsigc++? I notice it's been fixed in their > repository so I'll do up a new sigc++ mini-dist. > > Allan. (ARRae) > > Allan Thanks! I didn't know sigc++ wasn't part of the LyX project, so I didn't report this to anyone before yesterday. Lior.
Re: Lost math bindings
Alejandro Aguilar Sierra wrote:
>
> On 21 Sep 2000, Jean-Marc Lasgouttes wrote:
>
> > So, if we get rid of the math menu, should we keep the math bindings
> > on M-m? I think if we don't, there will be a riot from users, but Lars
> > disagrees...
>
> Yes, LyX had the hability to give users the choice to use the interface
> they liked the more. Is really necessary to take away that?
>
> > Amir> Sorry! I meant "\right(" et al. Tried it out in LyX and I get a
> > Amir> red "right" plus a blue (, which isn't what I want.
> >
> > One of these thing that mathed only half knows about...
>
> Is the produced latex right? Why don't you use M-m C ?
It doesn't work anymore :( I assume you meant M-m (
> Alejandro
>
> (Not very active LyX developer by now but still an user)
For the menu bindings I would prefer M-Sm and M-m for math.
Things are M-essed up now.
Garst
Re: Lost math bindings
On Thu, 21 Sep 2000, Garst R. Reese wrote: > > Is the produced latex right? Why don't you use M-m C ? > It doesn't work anymore :( I assume you meant M-m ( Yes, of course. I have not followed this thread but it seems that the philosofy has changed. Users won't have anymore the flexiblity to change the interface how ever they like. Unless there are very good reasons for that, this is a shame. Alejandro
patch
Attached is a patch rendering InsetError GUI-independent, together with an
xforms implementation of the associated dialog.
I've implemented the FormError dialog by defining a new base class, FormBase.
I think that this could be the base class for all the xforms dialogs.
Thoughts? Allan?
I've also modified the kde Makefile, Dialogs.C to add the new xforms dialog.
I have not done this to the gnome frontend, because I can't (yet?) test it
out.
Incidentally, I notice that kde/Dialogs.C and xforms/Dialogs.C differ.
Shouldn't they be identical? See below.
Lars, I have finally got round to installing ssh. How about that cvs access
now, at least so that I can "cvs add"
Angus
diff -u frontends/kde/Dialogs.C frontends/xforms/Dialogs.C
--- frontends/kde/Dialogs.C Thu Sep 21 19:37:15 2000
+++ frontends/xforms/Dialogs.C Thu Sep 21 19:21:43 2000
@@ -19,6 +19,9 @@
#pragma implementation
#endif
+// temporary till ported
+extern void ShowCredits();
+
Dialogs::Dialogs(LyXView * lv)
{
@@ -34,6 +37,8 @@
dialogs_.push_back(new FormTabular(lv, this));
dialogs_.push_back(new FormToc(lv, this));
dialogs_.push_back(new FormUrl(lv, this));
+
+ showCredits.connect(slot(ShowCredits));
// reduce the number of connections needed in
// dialogs by a simple connection here.
patch21Sep2000.tar.bz2
Re: inset questions
On Thu, 21 Sep 2000, Angus Leeming wrote: > I see that the following files in src/insets still #include FORMS_H_LOCATION: > > figinset.C, form_graphics.C, form_graphics.h, insetbib.C, inseterror.h, > insetexternal.C, insetinclude.C, insetinfo.h > > Are form_graphics.[Ch] to be made redundant by Baruch's efforts in this > direction? What about figinset.[Ch]? The form_graphics.[Ch] in the insets/ directory are obsoleted together with the figinset.[Ch], however since my FormGraphics is still not up to par with the figinset (no inline viewing) it probably should not be removed for now. I'll be back to my development machine tommorow and will try to finish the parts that still need work. I'll be replacing my devel machine and be back to work on FormGraphics. Baruch
Re: cvs --with-pspell no go
On Tue, 19 Sep 2000, Juergen Vigna wrote: > > On 19-Sep-2000 Kevin Atkinson wrote: > > > Um in a previous email: > > > > Date: Mon, 4 Sep 2000 06:26:38 -0400 (EDT) > > From: Kevin Atkinson <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: Two letter ISO 639 language code? > > > > In order to spell checker in other languages in Pspell the two letter > > ISO 639 language code is needed. Is there a way to get this? Or do I > > need to create a lookup table from the ispell language name to the code? > > > > I also need the country code in some cases, like for using the Canadian > > dictionary. > > Ok we already decided to add this language_country code so that you can > use it later. Um where. How do I use it? I also need the country code for languages which you have down such as "american" may I suggest you use the standard syntax which will be _ for example american will be "en_US". I also need a way know the encoding that LyX will be sending the TeX in. The current known encodings are ``utf-8'', ``iso8859-*'', ``koi8-r'', ``viscii'', ``cp1252'', ``machine unsigned 16'', ``machine unsigned 32''. Case does not matter. Kevin Atkinson kevina at users sourceforge net http://metalab.unc.edu/kevina/
Re: inset questions
On Thu, 21 Sep 2000, Angus Leeming wrote: > I see that the following files in src/insets still #include FORMS_H_LOCATION: > > figinset.C, form_graphics.C, form_graphics.h, insetbib.C, inseterror.h, > insetexternal.C, insetinclude.C, insetinfo.h > > Are form_graphics.[Ch] to be made redundant by Baruch's efforts in this > direction? What about figinset.[Ch]? > > This leaves the 5 inset files and associated classes. I was going to have a > go at making InsetInfo GUI-independent, but have vague notions that people > were suggesting that it too should go? (I haven't been paying much attention > of late) Is this so or should I do my worst on it? Info will become a collapsible inset and so it won't be needing a dialog in future. It should be fairly easy to implement (give it a better name at the same time like InsetProofread or something since it's meant for sticking editting notes into and should be possible to block export to certain formats (eg. ascii text). You work on one of the others, although InsetExternal and InsetGraphics are likely to be merged at some point (I think you were away for those threads) so you might just skip external for now. There's always fine-tuning to do if you need some work to do ;-) Allan. (ARRae)
