On Tue, Jul 01, 2003 at 11:01:30PM +0100, John Levon wrote:
> > > `class ControlRef'
> >
> > As far as I understand it, this is a naming clash. Qt has a
> > typedef struct OpaqueControlRef *ControlRef;
>
> Has anyone reported this stupid bug to Troll Tech yet ?
They are as guilty as we are.
An
Fernando Perez wrote:
> Crash mode: start new document, press Alt-I-S (insert special character).
> The 'Special' menu entry does NOT get highlighted, as it should. Now,
> press right arrow. Lyx crashes.
It's a qt bug. I can reproduce this kind of crash with any qt or kde app of my
choice (kma
I mailed Trolltech about the discussion, and there reply is:
I agree, you can safely remove it from qwindowdefs.h. Originally it was
thought to be necessary for future plans, but not.
However, using ControlRef might be a bad idea in any event as it is a
type in Carbon so including some headers cou
Hi Fernando
my computer is currently rh8.0 [1] with all current redhat updates.
Using a locally compiled lyx qt binary , does NOT crash following your
procedure.
Note my qt libs are older than yours.
[EMAIL PROTECTED] john]$ ldd `which lyx`
libqt-mt.so.3 => /usr/lib/qt-3.0.5/lib/libqt-mt
Alfredo Braunstein wrote:
I don't know if I've mentioned it, but I have Redhat 9, with the provided qt
3.1.1-6 and I cannot reproduce it at all.
More specifically (in case it helps you guys), I'm using RedHat 8.0, but I
updated my qt/kde from freshrpms.org to:
kdelibs-3.1.2-0.fdr.3.rh80
qt-3.1.2
/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104:
conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous
declaration as
`class ControlRef'
As far as I understand it, this is a naming clash. Qt has a
typedef struc
On 2003-07-01, 20:42 GMT, Alfredo Braunstein wrote:
>> way. Someone suggested that my build might be on top of incompatible
>> libraries and includes, but did not suggest how to investigate this.
>
> It seems that we have to discard this, since you (and others) get the same
> with the precompiled
John Levon <[EMAIL PROTECTED]> writes:
> On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
>
> > > /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
> > > types for `typedef struct OpaqueControlRef * ControlRef'
> > > ../../../src/frontends/controllers/Co
On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
> > /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
> > types for `typedef struct OpaqueControlRef * ControlRef'
> > ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
> > `class
- Forwarded message from [EMAIL PROTECTED] -
From: [EMAIL PROTECTED]
Date: Tue, 1 Jul 2003 13:26:09 -0700
To: Alfredo Braunstein <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Really, nothing further on qt menu fails?
On Tue, Jul 01, 2003 at 08:25:26PM +0200, Alfredo Braunstein wrote
Fernando Perez wrote:
> Anyway, enabling core files doesn't seem to help much, as the lyx.org rpms
> have no debugging info in them. Sorry, but I don't have time right now to
Ah yes, forgot about that.
Thanks anyway, Alfredo
[EMAIL PROTECTED] wrote:
> way. Someone suggested that my build might be on top of incompatible
> libraries and includes, but did not suggest how to investigate this.
It seems that we have to discard this, since you (and others) get the same
with the precompiled version/with standard systems.
Yes, Fernando. I experience the same failure, and posted the exact same screen
copy of gdb output to the lyx-devel list last Friday. I can't get my
environment to survive the crash either, but ONLY under gdb, oddly.
No one has offered up an answer, and others suggest everything works the right
w
James Frye wrote:
On Tue, 1 Jul 2003, Robin Turner wrote:
or
simulacra - see simulacrum
simulacrum, 6, 8, 16
A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index. I would love to have an option in the index
generator that says A and B are equivalent,
--NMuMz9nt05w80d4+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
* Matej Cepl <[EMAIL PROTECTED]>, 2003-07-01 14:22 -0400:
> On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
> > Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2, u
On Tue, 1 Jul 2003, Robin Turner wrote:
> or
>
> simulacra - see simulacrum
> simulacrum, 6, 8, 16
A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index. I would love to have an option in the index
generator that says A and B are equivalent, so both A an
Alfredo Braunstein wrote:
Could you try to get a complete backtrace? Not running kde, or
enabling/using a core file maybe helps.
Under Gnome it's even a bit worse: after killing gdb and reentering X, the
mouse pointer disappears! Hitting Alt-F1 to get a keyboard menu seems to
resucitate the poi
Fernando Perez wrote:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 17855)]
> 0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from
> /usr/lib/qt-3.1/lib/libqt-mt.so.3
> (gdb) Killed
>
> lyx: SIGHUP signal caught
> Bye.
> [~]> Mutex destroy failure
On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
> Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2, using the Lyx.org supplied
> rpms.
I've got the same with Debian 3.0, KDE 3.1.2, LyX 1.3.2 compiled by hand
on my computer.
This is the end of gdb story:
(no debugging symbols found)...(no debug
Hi all,
I'm not subscribed to lyx-dev and I just have already too many email lists.
But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I
figured I'd add a bit of info in case it helps the developers.
Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2, using the Lyx.org suppl
Thanks for all the reply. I do use qt lyx.
On Tuesday 01 July 2003 09:20, Jean-Marc Lasgouttes wrote:
> > "Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:
>
> Guanglei> However, what I experienced is that the absolute path is
> Guanglei> used even if the included files are in the same d
> "Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:
Guanglei> However, what I experienced is that the absolute path is
Guanglei> used even if the included files are in the same directory as
Guanglei> the lyx file, which is my case and I started lyx always in
Guanglei> the directory where
However, what I experienced is that the absolute path is used even if the
included files are in the same directory as the lyx file, which is my case
and I started lyx always in the directory where the lyx file lives.
Regards,
On Tuesday 01 July 2003 04:52, Jean-Marc Lasgouttes wrote:
> > "
Uz.ytkownik Jean-Marc Lasgouttes napisa?:
"Marcin" == Marcin Bukat <[EMAIL PROTECTED]> writes:
Marcin> Hmm. I see the same bug in xforms version. If included file is
Marcin> in 'parent directory' path is absolute.
The algorithm used currently is:
* compute the included file path relative to the
> "Marcin" == Marcin Bukat <[EMAIL PROTECTED]> writes:
Marcin> Hmm. I see the same bug in xforms version. If included file is
Marcin> in 'parent directory' path is absolute.
The algorithm used currently is:
* compute the included file path relative to the document path
* if this relative pa
Uz.ytkownik Jean-Marc Lasgouttes napisa?:
"Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:
Guanglei> Thanks, but can this be automatic? Can this be done through
Guanglei> working directory setting?
What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.
JMar
> "Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:
Guanglei> Thanks, but can this be automatic? Can this be done through
Guanglei> working directory setting?
What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.
JMarc
27 matches
Mail list logo
