Am 07.12.2021 um 07:38 schrieb Stephan Witt :
>
> Am 06.12.2021 um 14:43 schrieb Christoph Schmitz :
>>
>> Stephan,
>>
>> Many thanks! Adding the new config parameter
>> "--with-macos-deployment-target=11.1" solved the issue. On both computers.
>
> Ok, that’s fine.
>
>> Qt is installed on my
Am 06.12.2021 um 14:43 schrieb Christoph Schmitz :
>
> Stephan,
>
> Many thanks! Adding the new config parameter
> "--with-macos-deployment-target=11.1" solved the issue. On both computers.
Ok, that’s fine.
> Qt is installed on my system via homebrew. The currently installed version is
> 6.2.
Stephan,
Many thanks! Adding the new config parameter
"--with-macos-deployment-target=11.1" solved the issue. On both computers.
Qt is installed on my system via homebrew. The currently installed version is
6.2.2.
Chris
> Am 06.12.2021 um 07:35 schrieb Stephan Witt :
>
> Am 06.12.2021 um 06
Am 06.12.2021 um 06:25 schrieb Christoph Schmitz :
>
> I compile LyX on two MacBooks (one Intel Core i7, and one Apple M1), both
> running macOS 12.1 Beta (21C5045a).
Sorry, this doesn’t answer the question about your Qt version.
The error message tells us it’s impossible to compile LyX with yo
I compile LyX on two MacBooks (one Intel Core i7, and one Apple M1), both
running macOS 12.1 Beta (21C5045a).
Chris
> Am 05.12.2021 um 22:49 schrieb Stephan Witt :
>
> Am 05.12.2021 um 22:32 schrieb Christoph Schmitz :
>>
>> The latest changes have introduced an issue for macOS X (Qt 6).
>
>
Am 05.12.2021 um 22:32 schrieb Christoph Schmitz :
>
> The latest changes have introduced an issue for macOS X (Qt 6).
What’s your Qt version? I’m using 6.2.0 on macOS 11.1 (with 11.1 SDK) and it
works with minimum of macOS 10.14.
Stephan
>
> These are the last lines of the output before the
Am Fri, 23 Oct 2020 19:41:48 +0200
schrieb Jean-Marc Lasgouttes :
> Le 23/10/2020 à 13:23, Kornel Benko a écrit :
> > Am Fri, 23 Oct 2020 11:51:01 +0200
> > schrieb Kornel Benko :
> >
> >> Compiled with --std=c++17
> >>
> >> /usr2/src/lyx/lyx-git/src/support/docstream.cpp:280:32: error: invalid
Le 23/10/2020 à 13:23, Kornel Benko a écrit :
Am Fri, 23 Oct 2020 11:51:01 +0200
schrieb Kornel Benko :
Compiled with --std=c++17
/usr2/src/lyx/lyx-git/src/support/docstream.cpp:280:32: error: invalid
conversion from
‘char**’ to ‘const char**’ [-fpermissive] size_t converted = iconv(cd,
cons
Am Fri, 23 Oct 2020 11:51:01 +0200
schrieb Kornel Benko :
> Compiled with --std=c++17
>
> /usr2/src/lyx/lyx-git/src/support/docstream.cpp:280:32: error: invalid
> conversion from
> ‘char**’ to ‘const char**’ [-fpermissive] size_t converted = iconv(cd,
> const_cast ICONV_CONST **>(from), ^~~
Am Mittwoch, 20. Mai 2015 um 12:16:44, schrieb Jean-Marc Lasgouttes
> Le 20/05/2015 12:13, Kornel Benko a écrit :
> > Thanks Jean-Marc. If I understood correctly we need this define
> > only if using g++11 extension?
>
> No, whenever we enable C++11 (gcc, clang, visual studio...).
>
> JMarc
Th
Le 20/05/2015 12:13, Kornel Benko a écrit :
Thanks Jean-Marc. If I understood correctly we need this define
only if using g++11 extension?
No, whenever we enable C++11 (gcc, clang, visual studio...).
JMarc
Am Mittwoch, 20. Mai 2015 um 11:33:20, schrieb Jean-Marc Lasgouttes
> Le 20/05/2015 11:30, Kornel Benko a écrit :
> > All of sudden I get this error:
>
> It's my fault. Now autotools declares LYX_USE_CXX11 when needed and the
> code uses this macro instead of comparing value of __cplusplus. Thi
Le 20/05/2015 11:31, Mayank Jha a écrit :
Guys please remove me from the mailing list, I have been trying for many
days now! Please do it.
Hello,
Assuming that you have read http://www.lyx.org/MailingLists#toc11, did
you try to send a message to
lyx-devel-unsubscr...@lists.lyx.org
?
Assum
Le 20/05/2015 11:30, Kornel Benko a écrit :
All of sudden I get this error:
It's my fault. Now autotools declares LYX_USE_CXX11 when needed and the
code uses this macro instead of comparing value of __cplusplus. This is
because gcc 4.6 and earlier do not declare __cplusplus as they should.
Guys please remove me from the mailing list, I have been trying for many
days now! Please do it.
On Wed, May 20, 2015 at 3:00 PM, Kornel Benko wrote:
> All of sudden I get this error:
>
> [ 75%] Building CXX object src/CMakeFiles/lyx2.2.dir/CutAndPaste.cpp.o
> cd /usr/BUILD/BuildLyxGitQt5/src &&
On Mon, Dec 19, 2011 at 4:05 PM, Stephan Witt wrote:
>
> Hi Bennett,
>
> possibly you had my patch applied to correct the word count and your checkout
> is not clean?
>
> Stephan
Yep -- that was it. Thanks.
BH
On Sun, May 1, 2011 at 10:33 AM, Vincent van Ravesteijn wrote:
> On 1-5-2011 16:28, BH wrote:
>> I haven't tried compiling branch in a while, but trying today leads to
>> a compile error (using Qt-4.4):
>
>
> This is the error:
>
> "This file was generated using the moc from 4.7.1. It
> cannot be
On 1-5-2011 16:28, BH wrote:
> I haven't tried compiling branch in a while, but trying today leads to
> a compile error (using Qt-4.4):
This is the error:
"This file was generated using the moc from 4.7.1. It
cannot be used with the include files from this version of Qt.
(The moc has changed too
BH wrote:
> I haven't tried compiling branch in a while, but trying today leads to
> a compile error (using Qt-4.4):
Did you try with a make distclean'ed tree?
Jürgen
Andre Poenitz wrote:
Buffer const & bufOn Wed, Sep 23, 2009 at 10:20:02PM +0200, Kornel Benko wrote:
Abdel, my compiler does not like me ...
/usr/src/lyx/lyx-devel/src/frontends/qt4/GuiView.cpp: In member function ‘bool
lyx::frontend::GuiView::goToFileRow(const std::string&)’:
/usr/src/lyx/l
Buffer const & bufOn Wed, Sep 23, 2009 at 10:20:02PM +0200, Kornel Benko wrote:
> Abdel, my compiler does not like me ...
> /usr/src/lyx/lyx-devel/src/frontends/qt4/GuiView.cpp: In member function
> ‘bool lyx::frontend::GuiView::goToFileRow(const std::string&)’:
> /usr/src/lyx/lyx-devel/src/fronte
On Mon, 22 Sep 2008, Andre Poenitz wrote:
i guess everybody signed here http://wiki.lyx.org/Devel/LyXMeeting2008
will get the info, so just add yourself.
André, will you add some invitational details to the page, or will you
send your address etc via e-mail [off-list]?
I will send details of
On Mon, Sep 22, 2008 at 01:03:59PM +0200, Christian Ridderström wrote:
> On Mon, 22 Sep 2008, Pavel Sanda wrote:
>
>> Kornel Benko wrote:
>> Maybe we will see you in Berlin?
>>
>> I will also try to come.
>
> Thanks, I would like, but I fear, I will be of little help.
On Mon, 22 Sep 2008, Pavel Sanda wrote:
Kornel Benko wrote:
Maybe we will see you in Berlin?
I will also try to come.
Thanks, I would like, but I fear, I will be of little help.
The would be no valid argument, even if it were true, which I doubt.
In this case I want at least to see you a
Kornel Benko wrote:
> > > > Maybe we will see you in Berlin?
> > > >
> > > > I will also try to come.
> > >
> > > Thanks, I would like, but I fear, I will be of little help.
> >
> > The would be no valid argument, even if it were true, which I doubt.
>
> In this case I want at least to see you all
Am Sonntag 21 September 2008 schrieb Andre Poenitz:
> On Sun, Sep 21, 2008 at 12:39:08AM +0200, Kornel Benko wrote:
> > Am Samstag 20 September 2008 schrieb Peter Kümmel:
> > > Kornel Benko wrote:
> > > > -- Kornel Benko [EMAIL PROTECTED]
> > >
> > > Maybe we will see you in Berlin?
> > >
> > > I w
On Sun, Sep 21, 2008 at 12:39:08AM +0200, Kornel Benko wrote:
> Am Samstag 20 September 2008 schrieb Peter Kümmel:
> > Kornel Benko wrote:
> > > -- Kornel Benko [EMAIL PROTECTED]
> >
> > Maybe we will see you in Berlin?
> >
> > I will also try to come.
>
> Thanks, I would like, but I fear, I will
Am Samstag 20 September 2008 schrieb Peter Kümmel:
> Kornel Benko wrote:
> > -- Kornel Benko [EMAIL PROTECTED]
>
> Maybe we will see you in Berlin?
>
> I will also try to come.
Thanks, I would like, but I fear, I will be of little help.
> Peter
Kornel
--
Kornel Benko
[EMAIL PROTECTED]
Kornel Benko wrote:
-- Kornel Benko [EMAIL PROTECTED]
Maybe we will see you in Berlin?
I will also try to come.
Peter
Am Saturday 20 September 2008 schrieb Abdelrazak Younes:
> On 20/09/2008 09:02, Kornel Benko wrote:
> > Hi,
> > the newest r26461 does not compile on ubuntu.
> > (Revision 26459 compiles fine)
>
> Should be fixed, sorry.
It is. Fast as ever :)
Kornel
--
Kornel Benko
[EMAIL PROTECTED]
On 20/09/2008 09:02, Kornel Benko wrote:
Hi,
the newest r26461 does not compile on ubuntu.
(Revision 26459 compiles fine)
Should be fixed, sorry.
Abdel.
Kornel Benko wrote:
Am Mittwoch, 28. November 2007 schrieb José Matos:
On Wednesday 28 November 2007 16:48:36 Jean-Marc Lasgouttes wrote:
I had that recently in a clean tree. :-(
That is weird... What do you call 'clean'?
A fresh checkout. I tested this on the machine I use to track Fedora
Am Mittwoch, 28. November 2007 schrieb José Matos:
> On Wednesday 28 November 2007 16:48:36 Jean-Marc Lasgouttes wrote:
> > >
> > > I had that recently in a clean tree. :-(
> >
> > That is weird... What do you call 'clean'?
>
> A fresh checkout. I tested this on the machine I use to track Fedo
On Wednesday 28 November 2007 16:48:36 Jean-Marc Lasgouttes wrote:
> >
> > I had that recently in a clean tree. :-(
>
> That is weird... What do you call 'clean'?
A fresh checkout. I tested this on the machine I use to track Fedora
development branch (rawhide).
> JMarc
--
José Abílio
José Matos <[EMAIL PROTECTED]> writes:
> On Wednesday 28 November 2007 07:51:00 [EMAIL PROTECTED] wrote:
>> > *** No rule to make target `../ButtonPolicy.cpp', needed by
>> > `ButtonPolicy.lo'. Stop.
>>
>> try "make distclean". this is an automake dependency tracking bug,
>> I think.
>
> I had
On Wednesday 28 November 2007 07:51:00 [EMAIL PROTECTED] wrote:
> > *** No rule to make target `../ButtonPolicy.cpp', needed by
> > `ButtonPolicy.lo'. Stop.
>
> try "make distclean". this is an automake dependency tracking bug,
> I think.
I had that recently in a clean tree. :-(
> JMarc
--
> *** No rule to make target `../ButtonPolicy.cpp', needed by
> `ButtonPolicy.lo'. Stop.
try "make distclean". this is an automake dependency tracking bug,
I think.
JMarc
Bennett Helm <[EMAIL PROTECTED]> writes:
> Have you already applied this patch?
Yes :)
> Anyway, with current svn, I've reconfigured with --disable-aiksaurus,
> and I don't get any more configure warnings. Compilation succeeds.
Very good. This one was particularly difficult to track down.
JMar
On Aug 17, 2007, at 4:05 AM, Jean-Marc Lasgouttes wrote:
Bennett Helm <[EMAIL PROTECTED]> writes:
I decided to try playing around with settings to see if I could
get things to work for me. It turns out that the culprit for me
was --
without-aiksaurus: leaving everything else in my config
Bennett Helm <[EMAIL PROTECTED]> writes:
> I decided to try playing around with settings to see if I could get things
> to work for me. It turns out that the culprit for me was --
> without-aiksaurus: leaving everything else in my configure line the
> same but removing that option (and opting f
On Aug 14, 2007, at 3:11 AM, Jean-Marc Lasgouttes wrote:
Anders Ekberg <[EMAIL PROTECTED]> writes:
I have the same as Bennett:
/* Define to `int' if doesn't define. */
#define uid_t int
We found out that this is related to a string of errors in config.log,
but still have no idea of why.
Anders Ekberg <[EMAIL PROTECTED]> writes:
> I have the same as Bennett:
> /* Define to `int' if doesn't define. */
> #define uid_t int
We found out that this is related to a string of errors in config.log,
but still have no idea of why.
JMarc
On 13 aug 2007, at 23.43, Jean-Marc Lasgouttes wrote:
Anders Ekberg <[EMAIL PROTECTED]> writes:
I get the same.
usr/include/sys/signal.h:183 contains:
#ifndef _UID_T
#define _UID_T
typedef __darwin_uid_t uid_t; <- 183
#endif
And what do you have in src/config.h?
JMarc
Bennett Helm <[EMAIL PROTECTED]> writes:
> Changing trunk to this, allows compilation to proceed a little bit
> before I get:
Can we see you whole config.log? Send it to me privately if it is
huge.
JMarc
On Aug 13, 2007, at 6:43 PM, Jean-Marc Lasgouttes wrote:
Bennett Helm <[EMAIL PROTECTED]> writes:
On Aug 13, 2007, at 6:11 PM, Jean-Marc Lasgouttes wrote:
Bennett Helm <[EMAIL PROTECTED]> writes:
Not sure exactly what you're looking for. Here are the bits of
config.h relevant to uid_t:
T
Bennett Helm <[EMAIL PROTECTED]> writes:
> On Aug 13, 2007, at 6:11 PM, Jean-Marc Lasgouttes wrote:
>
>> Bennett Helm <[EMAIL PROTECTED]> writes:
>>
>>> Not sure exactly what you're looking for. Here are the bits of
>>> config.h relevant to uid_t:
>>
>> This is apple's signal.h. I want LyX' config
On Aug 13, 2007, at 6:11 PM, Jean-Marc Lasgouttes wrote:
Bennett Helm <[EMAIL PROTECTED]> writes:
Not sure exactly what you're looking for. Here are the bits of
config.h relevant to uid_t:
This is apple's signal.h. I want LyX' config.h.
That's what I get for rushing. Here is the relevant b
Bennett Helm <[EMAIL PROTECTED]> writes:
> Not sure exactly what you're looking for. Here are the bits of
> config.h relevant to uid_t:
This is apple's signal.h. I want LyX' config.h.
JMarc
On Aug 13, 2007, at 4:34 PM, Jean-Marc Lasgouttes wrote:
Bennett Helm <[EMAIL PROTECTED]> writes:
On Aug 13, 2007, at 4:19 PM, Jean-Marc Lasgouttes wrote:
Bennett Helm <[EMAIL PROTECTED]> writes:
/usr/include/sys/signal.h:183: error: two or more data types in
declaration specifiers
Could
Anders Ekberg <[EMAIL PROTECTED]> writes:
> I get the same.
>
> usr/include/sys/signal.h:183 contains:
>
> #ifndef _UID_T
> #define _UID_T
> typedef __darwin_uid_tuid_t; <- 183
> #endif
>
And what do you have in src/config.h?
JMarc
Jean-Marc Lasgouttes
Mon, 13 Aug 2007 13:20:26 -0700
Bennett Helm <[EMAIL PROTECTED]> writes:
> /usr/include/sys/signal.h:183: error: two or more data types in
> declaration specifiers
Could you show us what this line contains?
JMarc
I get the same.
usr/include/sys/signal.h:183 contains:
#
Bennett Helm <[EMAIL PROTECTED]> writes:
> On Aug 13, 2007, at 4:19 PM, Jean-Marc Lasgouttes wrote:
>
>> Bennett Helm <[EMAIL PROTECTED]> writes:
>>
>>> /usr/include/sys/signal.h:183: error: two or more data types in
>>> declaration specifiers
>>
>> Could you show us what this line contains?
>
> t
On Aug 13, 2007, at 4:19 PM, Jean-Marc Lasgouttes wrote:
Bennett Helm <[EMAIL PROTECTED]> writes:
/usr/include/sys/signal.h:183: error: two or more data types in
declaration specifiers
Could you show us what this line contains?
typedef __darwin_uid_t uid_t;
Bennett
Bennett Helm <[EMAIL PROTECTED]> writes:
> /usr/include/sys/signal.h:183: error: two or more data types in
> declaration specifiers
Could you show us what this line contains?
JMarc
InsetMathMBox is compiled only with CMake. That's because I wanted to
make sure that it stays compilable until it's time to use it.
I was thinking that scons (or worse, gcc) is broken. :-)
Bo
Stefan Schimanski wrote:
drawMarkers moved to InsetMathNest?! See r18701. Please revert or fix that.
/Users/sts/Quellen/mac/lyx-devel/src/mathed/InsetMathMBox.cpp: In member
function 'virtual void lyx::InsetMathMBox::draw(lyx::PainterInfo&, int,
int) const':
/Users/sts/Quellen/mac/lyx-devel/sr
On Thu, Jun 07, 2007 at 04:36:56PM -0500, Bo Peng wrote:
> On 6/7/07, Bo Peng <[EMAIL PROTECTED]> wrote:
> >On 6/7/07, Stefan Schimanski <[EMAIL PROTECTED]> wrote:
> >> drawMarkers moved to InsetMathNest?! See r18701. Please revert or fix
> >> that.
>
> The patch is partially reverted to move draw
On Thu, Jun 07, 2007 at 04:06:47PM -0500, Bo Peng wrote:
> On 6/7/07, Stefan Schimanski <[EMAIL PROTECTED]> wrote:
> >drawMarkers moved to InsetMathNest?! See r18701. Please revert or fix
> >that.
>
> Interesting, why my compiler did not complain? (The test was also
> tested by others).
>
> I wil
Strange, maybe my checkout it broken. But as far as I could see with
my tired eyes yesterday the mentioned patch moves drawMarkers from
InsetMath to InsetMathNest. And as InsetMathMBox is derived from the
former there should be an error, no?!
Stefan
On Thursday 07 June 2007 22:06:47 Bo Pe
On Thursday 07 June 2007 22:06:47 Bo Peng wrote:
> Interesting, why my compiler did not complain? (The test was also
> tested by others).
I had no problems with gcc 4.1.2 (with bits from 4.2) or else I would have
complained earlier. :-)
--
José Abílio
On 6/7/07, Bo Peng <[EMAIL PROTECTED]> wrote:
On 6/7/07, Stefan Schimanski <[EMAIL PROTECTED]> wrote:
> drawMarkers moved to InsetMathNest?! See r18701. Please revert or fix
> that.
The patch is partially reverted to move drawMarkers and drawMarkers2
back to its original place. The problem shou
On 6/7/07, Stefan Schimanski <[EMAIL PROTECTED]> wrote:
drawMarkers moved to InsetMathNest?! See r18701. Please revert or fix
that.
Interesting, why my compiler did not complain? (The test was also
tested by others).
I will see what is going on...
Bo
Jürgen Spitzmüller wrote:
ControlDocument.cpp: In member function 'int
lyx::frontend::ControlDocument::id() const':
ControlDocument.cpp:84: error: cast from 'const lyx::Buffer*' to 'int' loses
precision
make[7]: *** [ControlDocument.lo] Error 1
Hum, you have "warning as error" set apparently.
On Mon, 14 May 2007, Abdelrazak Younes wrote:
Try again. I wonder why people are so quick in reporting compil errors
but not so much in answering call for help :-(
Lack of ability (and time?) to review a patch? That's the case for me at
least.
/C
--
Christian Ridderström, +46-8-768 39 44
On May 14, 2007, at 10:26 AM, Abdelrazak Younes wrote:
Bennett Helm wrote:
Current svn:
Try again. I wonder why people are so quick in reporting compil
errors but not so much in answering call for help :-(
Abdel.
That does it. Thanks.
Bennett
Bennett Helm wrote:
Current svn:
Try again. I wonder why people are so quick in reporting compil errors
but not so much in answering call for help :-(
Abdel.
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> No, setText is some kind of new fancy qt 4,2 thing that
>> automatically detects whether the input is plain text or html.
>>
>> I'll commit
Bo> Thanks. I guess I should have used qt4.0 for the development.
I think we settled on 4.1 (except ma
No, setText is some kind of new fancy qt 4,2 thing that automatically
detects whether the input is plain text or html.
I'll commit
Thanks. I guess I should have used qt4.0 for the development.
Bo
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> I am not Bo but this is obviously correct. I guess Bo is
Abdelrazak> still using QT3Support or something...
No, setText is some kind of new fancy qt 4,2 thing that automatically
detects whether the input is plain text
Jean-Marc Lasgouttes wrote:
"Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> 'class QTextEdit' has no member named 'setText'
Martin> for QListings, QDocument and QInclude. Seems Listings related.
Martin> I have qt4-devel-4.1.5-2.fc4 installed and configure finds it.
Martin> qt3-
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> 'class QTextEdit' has no member named 'setText'
Martin> for QListings, QDocument and QInclude. Seems Listings related.
Martin> I have qt4-devel-4.1.5-2.fc4 installed and configure finds it.
Martin> qt3-devel has been intentiona
Georg Baum wrote:
Am Donnerstag, 1. Februar 2007 18:38 schrieb Abdelrazak Younes:
indeed. I fixed that.
It's weird that MSVC doesn't complain about that...
Are you sure that whatever LyXText::dispatch does to fr should be ignored?
Mostly yes.
IIRC I have seen reusage of cmd in similar ca
Am Donnerstag, 1. Februar 2007 18:38 schrieb Abdelrazak Younes:
> indeed. I fixed that.
> It's weird that MSVC doesn't complain about that...
Are you sure that whatever LyXText::dispatch does to fr should be ignored?
IIRC I have seen reusage of cmd in similar cases.
Georg
Georg Baum wrote:
../../src/text3.C: In member function ‘void
lyx::LyXText::dispatch(lyx::LCursor&, lyx::FuncRequest&)’:
../../src/text3.C:714: error: no matching function for call to
‘lyx::LyXText::dispatch(lyx::LCursor&, lyx::FuncRequest)’
../../src/text3.C:301: note: candidates are: void
lyx::
Peter Kümmel wrote:
> Fixed, search and replace is better than compiling when using msvc.
Thanks.
Georg
Georg Baum wrote:
> First I get a warning:
>
> ../../src/lyxfunc.C: In member function `void lyx::LyXFunc::dispatch(const
> lyx::FuncRequest&)':
> ../../src/lyxfunc.C:1671: warning: the address of
> `lyx::frontend::Application* lyx::theApp()', will always be `true'
>
> and then an error:
>
> ../
Peter Kümmel wrote:
> Helge Hafting wrote:
>> g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE
>> -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src
>> -I../../../src/frontends -I../../../images -DQT_SHARED
>> -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/
Helge Hafting wrote:
> g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE
> -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src
> -I../../../src/frontends -I../../../images -DQT_SHARED
> -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui
> -I../../../boost -
Am Donnerstag, 19. Oktober 2006 20:55 schrieb Asger Ottar Alstrup:
> I had to add
>
> using lyx::odocstream;
>
> at the top of InsetMathMBox.C, but now I get:
>
> InsetMathMBox.C
> ..\..\..\lyx-devel\src\mathed\InsetMathMBox.C(76) : error C2664:
> 'LyXText::write' : cannot convert parameter 2 f
Juergen Spitzmueller wrote:
> I'm gonna commit the attached patch.
Forget this. Lars already did this.
Jürgen
Abdelrazak Younes wrote:
> Try to #include "frontend/Gui.h"
If I do this and #include "frontends/Selection.h", it compiles again. I'm
gonna commit the attached patch.
Jürgen
Index: src/frontends/qt3/QWorkArea.C
===
--- src/frontends
Juergen Spitzmueller wrote:
Juergen Spitzmueller wrote:
QWorkArea.C: In function 'bool lyxX11EventFilter(XEvent*)':
QWorkArea.C:114: error: 'class LyXView' has no member named
'requestSelection'
This error is fixed with the attached patch.
No idea about the second one, though:
QWorkArea.C:1
Juergen Spitzmueller wrote:
> QWorkArea.C: In function 'bool lyxX11EventFilter(XEvent*)':
> QWorkArea.C:114: error: 'class LyXView' has no member named
> 'requestSelection'
This error is fixed with the attached patch.
No idea about the second one, though:
> QWorkArea.C:116: error: invalid use o
Michael Gerz schrieb:
On Windows/MinGW,
I get the following error message:
C:\msys\home\mg\lyx-trunk\src\buffer.C:116: error: `Path' is already
declared in this scope
Am I the only one getting this problem??? Might be a boost update problem...
Michael
Abdelrazak Younes wrote:
Edwin Leuven wrote:
Abdelrazak Younes wrote:
D:\devel\lyx\trunk2\src\frontends\qt4\Dialogs.C(318) : error C2061:
syntax error : identifier 'QURL'
Idea someone?
clash with qt headers?
Indeed. Weird that burns just now... I'll rename this class.
Done.
SVN LOG:
Edwin Leuven wrote:
Abdelrazak Younes wrote:
D:\devel\lyx\trunk2\src\frontends\qt4\Dialogs.C(318) : error C2061:
syntax error : identifier 'QURL'
Idea someone?
clash with qt headers?
Indeed. Weird that burns just now... I'll rename this class.
Thanks,
Abdel.
Abdelrazak Younes wrote:
D:\devel\lyx\trunk2\src\frontends\qt4\Dialogs.C(318) : error C2061:
syntax error : identifier 'QURL'
Idea someone?
clash with qt headers?
i changed this in qurl.h
-#ifndef QURL_H
-#define QURL_H
+#ifndef QLURL_H
+#define QLURL_H
On Fri, Jan 30, 2004 at 01:54:37PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | This intention of this 'nucleus/operator->' pair instead of the usual
> | 'nucleus/nucleus' pair was to be able to find the non-const accesses
> | with grep. [They are sort of 'un
Andre Poenitz <[EMAIL PROTECTED]> writes:
| This intention of this 'nucleus/operator->' pair instead of the usual
| 'nucleus/nucleus' pair was to be able to find the non-const accesses
| with grep. [They are sort of 'unwanted' in the light of potential
| shared_ptr usage and each use should be jus
On Wed, Jan 28, 2004 at 12:31:01PM +0100, Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>
> | Angus Leeming <[EMAIL PROTECTED]> writes:
> >
> | | Georg Baum wrote:
> >>> It compiles if I change line 838 of src/Cursor.C from
> >>>
> >>> if (t.operator->() != anchor_[
On Wed, Jan 28, 2004 at 12:10:48PM +0100, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Georg Baum wrote:
> >> It compiles if I change line 838 of src/Cursor.C from
> >>
> >> if (t.operator->() != anchor_[depth()].inset())
>
> I wonder what has been smoked here to
On Tue, Jan 27, 2004 at 09:58:19PM +, Angus Leeming wrote:
> Georg Baum wrote:
> > It compiles if I change line 838 of src/Cursor.C from
> >
> > if (t.operator->() != anchor_[depth()].inset())
> >
> > to
> >
> > if (t.operator->() !=
> > const_cast(anchor_[depth()].inset()))
> >
> > Is this
On Tue, Jan 27, 2004 at 10:09:12PM +0100, Georg Baum wrote:
> I get this error when compiling latest CVS with gcc 2.95 + stlport:
>
> g++ -DHAVE_CONFIG_H -I. -I../../src -I. -I../../boost
> -I/usr/include/stlport-I/usr/X11R6/include -DCXX_GLOBAL_CSTD
> -ftemplate-depth-30 -nostdinc++ -g -W
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>>> It compiles if I change line 838 of src/Cursor.C from
>>> if (t.operator->() != anchor_[depth()].inset())
>
| I wonder what has been smoked here to think this is a nice
| construct...
>>>
>> | Agreed.
Lars Gullik Bjønnes wrote:
>> It compiles if I change line 838 of src/Cursor.C from
>> if (t.operator->() != anchor_[depth()].inset())
>>> | I wonder what has been smoked here to think this is a nice
>>> | construct...
>>
> | Agreed. What I'm confused about is why operator->() behaves
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
> It compiles if I change line 838 of src/Cursor.C from
> if (t.operator->() != anchor_[depth()].inset())
>>>
>> | I wonder what has been smoked here to think this is a nice
>> | construct...
>
| Agreed. What I'm confus
Lars Gullik Bjønnes wrote:
It compiles if I change line 838 of src/Cursor.C from
if (t.operator->() != anchor_[depth()].inset())
>>
> | I wonder what has been smoked here to think this is a nice
> | construct...
Agreed. What I'm confused about is why operator->() behaves
differently. Ca
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Angus Leeming <[EMAIL PROTECTED]> writes:
>
| | Georg Baum wrote:
>>> It compiles if I change line 838 of src/Cursor.C from
>>>
>>> if (t.operator->() != anchor_[depth()].inset())
>
| I wonder what has been smoked here to think this is a nice
| co
Angus Leeming <[EMAIL PROTECTED]> writes:
| Georg Baum wrote:
>> It compiles if I change line 838 of src/Cursor.C from
>>
>> if (t.operator->() != anchor_[depth()].inset())
I wonder what has been smoked here to think this is a nice
construct...
--
Lgb
Georg Baum wrote:
> It compiles if I change line 838 of src/Cursor.C from
>
> if (t.operator->() != anchor_[depth()].inset())
>
> to
>
> if (t.operator->() !=
> const_cast(anchor_[depth()].inset()))
>
> Is this expected?
Don't think so. The two functions in question are:
MathInset const
1 - 100 of 183 matches
Mail list logo
