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
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?
> >
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
When my computer is even slightly overtasked, and particularly when
I'm making changes to the middle of existing lines, LyX seems to
*lose* any character that the computer is not capable of writing
immediately after I type it because of system constraints.
I'm using 1.1.5cvs.
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
Due to recent changes (replacing of char * by strings), there is a new bug in
mathed:
When inside the mathed, while typing \cos, no text is visible until pressing
space. I've attached a bug that fixes it.
patch.gz
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
ch
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
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
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 figi
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 rewrit
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... ;-)
>
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?
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
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.
> > 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
> r
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, wi
> "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 rea
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
co
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/incl
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 K
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/alee
* 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
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
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 Group
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../
On Thu, 21 Sep 2000, Angus Leeming wrote:
> Ok, I'm feeling pretty proud of myself. I've compiled and linked lyx with
> the kde frontend.
cool !
> Finally, the src/Makefile defines the qt and kdelibraries as:
> -lqt -lkdecore
> This results in lots of "can't find symbol" errors. On the
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 ../.
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,
29 matches
Mail list logo
