src/frontends/qt4/GuiWorkArea.cpp:1478: error: 'class QDrag' has no
member named 'exec'
Should we bump QT requirement to 4.3???
Bo
Bo Peng wrote:
src/frontends/qt4/GuiWorkArea.cpp:1478: error: 'class QDrag' has no
member named 'exec'
Should we bump QT requirement to 4.3???
Oh, no, not another one of THESE discussions! I think the last time we
discussed this issue, we came to some kind of agreement that we'd stay
"a
rgheck wrote:
Bo Peng wrote:
src/frontends/qt4/GuiWorkArea.cpp:1478: error: 'class QDrag' has no
member named 'exec'
Should we bump QT requirement to 4.3???
Oh, no, not another one of THESE discussions! I think the last time we
discussed this issue, we came to some kind of agreement that
> What to do about QDrag::exec is another question. Presumably Andre will
> have a good idea.
Why cannot people use qt 4.2 for development? We have had a lot of
compatibility problems with qt 4.3.
Bo
On Sat, Oct 13, 2007 at 11:51:47PM +0200, Uwe Stöhr wrote:
Unfortunately I could also not use Qt 4.2's designer - it doesn't start
because my system config is for Qt 4.3, and when I change the config back
to Qt 4.2, I couldn't compile using Qt 4.3.
Not sure what system config means in this
On Sat, Oct 13, 2007 at 11:51:47PM +0200, Uwe Stöhr wrote:
> Unfortunately I could also not use Qt 4.2's designer - it doesn't start
> because my system config is for Qt 4.3, and when I change the config back
> to Qt 4.2, I couldn't compile using Qt 4.3.
Not sure what "system config" means in
try1/src/frontends/qt4/ui/ui_HyperlinkUi.h: In member function 'void
Ui_HyperlinkUi::setupUi(QDialog*)':
try1/src/frontends/qt4/ui/ui_HyperlinkUi.h:45: error: 'class
QGridLayout' has no member named 'setLeftMargin'
try1/src/frontends/qt4/ui/ui_HyperlinkUi.h:46: error: 'class
QGridLayout' has no
This is because I used Qt 4.3's designer. I don't know why this doesn't compile with Qt 4.2. I
googled and couldn't found a hint on trolltech.com where this behaviour is described.
Unfortunately I could also not use Qt 4.2's designer - it doesn't start because my system config is
for Qt 4.3, and
For now the workaround is: open the layout with Qt 4.2's designer and save it.
I updated the ui file using qt422.
Bo
try1/src/frontends/qt4/ui/ui_HyperlinkUi.h: In member function 'void
Ui_HyperlinkUi::setupUi(QDialog*)':
try1/src/frontends/qt4/ui/ui_HyperlinkUi.h:45: error: 'class
QGridLayout' has no member named 'setLeftMargin'
try1/src/frontends/qt4/ui/ui_HyperlinkUi.h:46: error: 'class
QGridLayout' has no
This is because I used Qt 4.3's designer. I don't know why this doesn't compile with Qt 4.2. I
googled and couldn't found a hint on trolltech.com where this behaviour is described.
Unfortunately I could also not use Qt 4.2's designer - it doesn't start because my system config is
for Qt 4.3, and
> For now the workaround is: open the layout with Qt 4.2's designer and save it.
I updated the ui file using qt422.
Bo
g++ -o try1/src/MenuBackend.o -c
-I/home/bpeng/lyx-devel/lyx-1.6-rw/boost -g -O -Itry1/src -Isrc -Isrc
-Itry1/intl -Iintl src/MenuBackend.cpp
src/MenuBackend.cpp: In member function `lyx::Menu
lyx::Menu::read(lyx::Lexer)':
src/MenuBackend.cpp:306: error: `Elements' is not a member of
On Thu, 06 Sep 2007 10:01:31 -0500
Bo Peng [EMAIL PROTECTED] wrote:
g++ -o try1/src/MenuBackend.o -c
-I/home/bpeng/lyx-devel/lyx-1.6-rw/boost -g -O -Itry1/src -Isrc -Isrc
-Itry1/intl -Iintl src/MenuBackend.cpp
src/MenuBackend.cpp: In member function `lyx::Menu
lyx::Menu::read(lyx::Lexer)':
g++ -o try1/src/MenuBackend.o -c
-I/home/bpeng/lyx-devel/lyx-1.6-rw/boost -g -O -Itry1/src -Isrc -Isrc
-Itry1/intl -Iintl src/MenuBackend.cpp
src/MenuBackend.cpp: In member function `lyx::Menu&
lyx::Menu::read(lyx::Lexer&)':
src/MenuBackend.cpp:306: error: `Elements' is not a member of
On Thu, 06 Sep 2007 10:01:31 -0500
Bo Peng <[EMAIL PROTECTED]> wrote:
> g++ -o try1/src/MenuBackend.o -c
> -I/home/bpeng/lyx-devel/lyx-1.6-rw/boost -g -O -Itry1/src -Isrc -Isrc
> -Itry1/intl -Iintl src/MenuBackend.cpp
> src/MenuBackend.cpp: In member function `lyx::Menu&
>
src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined
type `struct QTabBar'
/home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error:
forward declaration of `struct QTabBar'
If this is another 4.3 only stuff, please make qt 4.3 the minimal
required version for lyx 1.6.0, OR
Bo Peng wrote:
src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined
type `struct QTabBar'
/home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error:
forward declaration of `struct QTabBar'
fixed.
A/
Alfredo Braunstein wrote:
Bo Peng wrote:
src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined
type `struct QTabBar'
/home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error:
forward declaration of `struct QTabBar'
fixed.
Thanks, sorry for the inconvenience.
Abdel.
Thanks, sorry for the inconvenience.
So this is another pch problem??? Please try to fix cmake.
Bo
Bo Peng wrote:
Thanks, sorry for the inconvenience.
So this is another pch problem???
Yes.
Please try to fix cmake.
This is not about fixing cmake but about me not being careful enough.
pch support can be disabled in CMake. In general I am careful with new
header but I forgot this
Please try to fix cmake.
This is not about fixing cmake but about me not being careful enough.
pch support can be disabled in CMake. In general I am careful with new
header but I forgot this time.
This is about cmake's allowing you to compile a lyx.exe without this header.
Bo
Bo Peng wrote:
Please try to fix cmake.
This is not about fixing cmake but about me not being careful enough.
pch support can be disabled in CMake. In general I am careful with new
header but I forgot this time.
This is about cmake's allowing you to compile a lyx.exe without this header.
??? That's the basic idea behind pch. The same thing would happen with
scons I think.
So you think this is acceptable? I did not add pch to scons because of
this exact reason. I want a reliable build more than performance.
Bo
Bo Peng wrote:
??? That's the basic idea behind pch. The same thing would happen with
scons I think.
So you think this is acceptable?
For day to day development, yes.
I did not add pch to scons because of
this exact reason. I want a reliable build more than performance.
On the contrary,
So you think this is acceptable?
For day to day development, yes.
But please try not to break the trunk.
On the contrary, for development I want performance first.
...
Bo
Bo Peng wrote:
So you think this is acceptable?
For day to day development, yes.
But please try not to break the trunk.
I am trying hard in general. Just not in this case.
Abdel.
src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined
type `struct QTabBar'
/home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error:
forward declaration of `struct QTabBar'
If this is another 4.3 only stuff, please make qt 4.3 the minimal
required version for lyx 1.6.0, OR
Bo Peng wrote:
> src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined
> type `struct QTabBar'
> /home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error:
> forward declaration of `struct QTabBar'
fixed.
A/
Alfredo Braunstein wrote:
Bo Peng wrote:
src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined
type `struct QTabBar'
/home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error:
forward declaration of `struct QTabBar'
fixed.
Thanks, sorry for the inconvenience.
Abdel.
>
> Thanks, sorry for the inconvenience.
So this is another pch problem??? Please try to fix cmake.
Bo
Bo Peng wrote:
Thanks, sorry for the inconvenience.
So this is another pch problem???
Yes.
Please try to fix cmake.
This is not about fixing cmake but about me not being careful enough.
pch support can be disabled in CMake. In general I am careful with new
header but I forgot this
> > Please try to fix cmake.
>
> This is not about fixing cmake but about me not being careful enough.
> pch support can be disabled in CMake. In general I am careful with new
> header but I forgot this time.
This is about cmake's allowing you to compile a lyx.exe without this header.
Bo
Bo Peng wrote:
Please try to fix cmake.
This is not about fixing cmake but about me not being careful enough.
pch support can be disabled in CMake. In general I am careful with new
header but I forgot this time.
This is about cmake's allowing you to compile a lyx.exe without this header.
> ??? That's the basic idea behind pch. The same thing would happen with
> scons I think.
So you think this is acceptable? I did not add pch to scons because of
this exact reason. I want a reliable build more than performance.
Bo
Bo Peng wrote:
??? That's the basic idea behind pch. The same thing would happen with
scons I think.
So you think this is acceptable?
For day to day development, yes.
I did not add pch to scons because of
this exact reason. I want a reliable build more than performance.
On the contrary,
> > So you think this is acceptable?
>
> For day to day development, yes.
But please try not to break the trunk.
> On the contrary, for development I want performance first.
...
Bo
Bo Peng wrote:
So you think this is acceptable?
For day to day development, yes.
But please try not to break the trunk.
I am trying hard in general. Just not in this case.
Abdel.
with qt 4.2.1:
g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -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
My copy of qt is 4.3.0. It must have added these. I'll remove them
manually. That should fix the problem.
rh
Georg Baum wrote:
with qt 4.2.1:
g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -I../../../src
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS
with qt 4.2.1:
g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -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
My copy of qt is 4.3.0. It must have added these. I'll remove them
manually. That should fix the problem.
rh
Georg Baum wrote:
with qt 4.2.1:
g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -I../../../src
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS
Bernhard Roider wrote:
Hello,
Changeset 17470 (http://www.lyx.org/trac/changeset/17470) removed the
default constructor from class OutputParams but it is needed by the
local variable runparams in the method InsetMathMBox::write(..)
i did the attached to make it compile. haven't seen any
Edwin Leuven wrote:
Bernhard Roider wrote:
Hello,
Changeset 17470 (http://www.lyx.org/trac/changeset/17470) removed the
default constructor from class OutputParams but it is needed by the
local variable runparams in the method InsetMathMBox::write(..)
i did the attached to make it
Bernhard Roider wrote:
Hello,
Changeset 17470 (http://www.lyx.org/trac/changeset/17470) removed the
default constructor from class OutputParams but it is needed by the
local variable runparams in the method InsetMathMBox::write(..)
i did the attached to make it compile. haven't seen any
Edwin Leuven wrote:
> Bernhard Roider wrote:
>> Hello,
>>
>> Changeset 17470 (http://www.lyx.org/trac/changeset/17470) removed the
>> default constructor from class OutputParams but it is needed by the
>> local variable runparams in the method InsetMathMBox::write(..)
>
> i did the attached to
Hello,
Changeset 17470 (http://www.lyx.org/trac/changeset/17470) removed the default constructor from class
OutputParams but it is needed by the local variable runparams in the method InsetMathMBox::write(..)
Bernhard
Hello,
Changeset 17470 (http://www.lyx.org/trac/changeset/17470) removed the default constructor from class
OutputParams but it is needed by the local variable runparams in the method InsetMathMBox::write(..)
Bernhard
101 - 148 of 148 matches
Mail list logo
