Qt-interest Archive, April 2008
Porting to/Developing in QT4
Message 1 in thread
Hi
I've got two significant apps that I developed under QT 3.3. I would like
to port one to QT4 and leave the other on QT 3.3 (only because it is too
big and too mature to bother). So, I'm trying to port the other much
smaller app. It's only got a few source files and half a dozen uis.
I'm running into difficulties:
1. I can compile and run the KDevelop QT4 sample app without any problems
so I think my installation (from Fedora 8 installation) is okay.
2. If I qt3toqt4 and upgrade my uis in designer-qt4 and qmake-qt4, etc. I
get a compile error in the code as follows:
...
targets::targets() : QMainWindow()
{
mww = new Ui_Form();
setCentralWidget(mww);
...
The error is that it cannot cast the Ui_Form to Widget*
I get this whether I use qt3support or not, whether I create the ui from
new or open qt3 and save as qt4.
3. Looking at the header file produced by uic-qt4 within qmake-qt4/make,
etc. the class definition lacks the hierarchy so:
...
class targets
{
public:
targets();
~targets();
...
The header file is also really strange in another way. It has all the
controls okay, but misses out most of the names I give them.
4. If I run uic-qt4 manually it puts the hierarchy in (and all the
controls get named as well) and then the programme compiles correctly. It
then stops at the same line with a segmentation fault. Running with debug
suggests that the mmw object is okay.
5. I've tried taking out the Q3 objects and going to pure QT4 so that I
can run without qt3support, but it makes no difference.
I'm not sure what is going on and so am finding it really hard to see
which way to go. My feeling is that it is something to do with 'features'
but I can't see anything wrong.
Thanks for any help.
Nick
--
[ signature omitted ]
Message 2 in thread
some remarks:
- qt3to4 doesn't do everything for you. in fact, it's just producing a starting point in your porting venture.
- qt4 has a different scheme for uic created objects - they're no longer widgets themselves, instead they are used to populate a widget, and to keep pointers to the subcontrols created.
- you can "simulate" the old qt3 way by multiinheriting from the uic generated object AND the widget of your choice.
- a better way (the qt4 way) is to have the uic generated object as a member object in your widget.
Cheers,
Peter
> -----Ursprüngliche Nachricht-----
> Von: npr@xxxxxxxxxxxxxxxx [mailto:npr@xxxxxxxxxxxxxxxx]
> Gesendet: Dienstag, 8. April 2008 17:36
> An: qt-interest@xxxxxxxxxxxxx
> Betreff: Porting to/Developing in QT4
>
> Hi
>
> I've got two significant apps that I developed under QT 3.3.
> I would like
> to port one to QT4 and leave the other on QT 3.3 (only
> because it is too
> big and too mature to bother). So, I'm trying to port the other much
> smaller app. It's only got a few source files and half a dozen uis.
>
> I'm running into difficulties:
>
> 1. I can compile and run the KDevelop QT4 sample app without
> any problems
> so I think my installation (from Fedora 8 installation) is okay.
>
> 2. If I qt3toqt4 and upgrade my uis in designer-qt4 and
> qmake-qt4, etc. I
> get a compile error in the code as follows:
>
> ...
> targets::targets() : QMainWindow()
> {
> mww = new Ui_Form();
>
> setCentralWidget(mww);
> ...
>
> The error is that it cannot cast the Ui_Form to Widget*
>
> I get this whether I use qt3support or not, whether I create
> the ui from
> new or open qt3 and save as qt4.
>
> 3. Looking at the header file produced by uic-qt4 within
> qmake-qt4/make,
> etc. the class definition lacks the hierarchy so:
>
> ...
> class targets
> {
>
> public:
> targets();
> ~targets();
> ...
>
> The header file is also really strange in another way. It has all the
> controls okay, but misses out most of the names I give them.
>
> 4. If I run uic-qt4 manually it puts the hierarchy in (and all the
> controls get named as well) and then the programme compiles
> correctly. It
> then stops at the same line with a segmentation fault.
> Running with debug
> suggests that the mmw object is okay.
>
> 5. I've tried taking out the Q3 objects and going to pure QT4
> so that I
> can run without qt3support, but it makes no difference.
>
> I'm not sure what is going on and so am finding it really hard to see
> which way to go. My feeling is that it is something to do
> with 'features'
> but I can't see anything wrong.
>
> Thanks for any help.
>
> Nick
>
> --
> To unsubscribe - send a mail to
> qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the
> subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 3 in thread
Btw. this is probably better explained in the docs:
http://doc.trolltech.com/4.3/porting4-designer.html#uic-output
http://doc.trolltech.com/4.3/porting4.html
> -----Ursprüngliche Nachricht-----
> Von: Peter Prade [mailto:prade@xxxxxxxxxxx]
> Gesendet: Dienstag, 8. April 2008 19:02
> An: qt-interest@xxxxxxxxxxxxx
> Betreff: AW: Porting to/Developing in QT4
>
> some remarks:
> - qt3to4 doesn't do everything for you. in fact, it's just
> producing a starting point in your porting venture.
> - qt4 has a different scheme for uic created objects -
> they're no longer widgets themselves, instead they are used
> to populate a widget, and to keep pointers to the subcontrols created.
> - you can "simulate" the old qt3 way by multiinheriting from
> the uic generated object AND the widget of your choice.
> - a better way (the qt4 way) is to have the uic generated
> object as a member object in your widget.
>
> Cheers,
> Peter
--
[ signature omitted ]
Message 4 in thread
npr@xxxxxxxxxxxxxxxx wrote:
> Hi
>
> I've got two significant apps that I developed under QT 3.3. I would like
> to port one to QT4 and leave the other on QT 3.3 (only because it is too
> big and too mature to bother). So, I'm trying to port the other much
> smaller app. It's only got a few source files and half a dozen uis.
>
> I'm running into difficulties:
>
> 1. I can compile and run the KDevelop QT4 sample app without any problems
> so I think my installation (from Fedora 8 installation) is okay.
>
> 2. If I qt3toqt4 and upgrade my uis in designer-qt4 and qmake-qt4, etc. I
> get a compile error in the code as follows:
>
> ...
> targets::targets() : QMainWindow()
> {
> mww = new Ui_Form();
>
> setCentralWidget(mww);
> ...
>
> The error is that it cannot cast the Ui_Form to Widget*
>
> I get this whether I use qt3support or not, whether I create the ui from
> new or open qt3 and save as qt4.
>
> 3. Looking at the header file produced by uic-qt4 within qmake-qt4/make,
> etc. the class definition lacks the hierarchy so:
>
> ...
> class targets
> {
>
> public:
> targets();
> ~targets();
> ...
>
> The header file is also really strange in another way. It has all the
> controls okay, but misses out most of the names I give them.
>
> 4. If I run uic-qt4 manually it puts the hierarchy in (and all the
> controls get named as well) and then the programme compiles correctly. It
> then stops at the same line with a segmentation fault. Running with debug
> suggests that the mmw object is okay.
>
> 5. I've tried taking out the Q3 objects and going to pure QT4 so that I
> can run without qt3support, but it makes no difference.
>
> I'm not sure what is going on and so am finding it really hard to see
> which way to go. My feeling is that it is something to do with 'features'
> but I can't see anything wrong.
>
>
>
Designer works much differently in Qt4 and in Qt3, but there is decent
backwards compatibility support using uic3. In Qt4 pretty much every
.ui needs to have some sort of subclass associated with it. If you used
the old ui.h method to extend the functionality of your forms you will
need to create subclasses of QWidget/Dialog that contain your extra
functionality. Luckily uic3 can generate this code for you. This is a
huge topic and I suggest watching the talk that I did at the 2006
Trolltech Dev Days on porting from Qt3 to Qt4 for the full rundown on
porting designer forms.
http://www.trolltechvideo.com/video/day1/room_c/c_1_4/video.html
Good Luck!
--Justin
begin:vcard
begin:vcard
fn:Justin Noel
n:Noel;Justin
org:ICS;Engineering
adr:;;54B Middlesex Trpk.;Bedford;MA;01730;USA
email;internet:justin@xxxxxxx
title:Sr. Consulting Engineer / Certified Qt Instructor
tel;work:617-621-0060
x-mozilla-html:FALSE
url:www.ics.com
version:2.1
end:vcard
Message 5 in thread
On Tuesday 08 April 2008 18:18:34 Justin Noel wrote:
> npr@xxxxxxxxxxxxxxxx wrote:
> > Hi
> >
> > I've got two significant apps that I developed under QT 3.3. I would like
> > to port one to QT4 and leave the other on QT 3.3 (only because it is too
> > big and too mature to bother). So, I'm trying to port the other much
> > smaller app. It's only got a few source files and half a dozen uis.
> >
> > I'm running into difficulties:
> >
> > 1. I can compile and run the KDevelop QT4 sample app without any problems
> > so I think my installation (from Fedora 8 installation) is okay.
> >
> > 2. If I qt3toqt4 and upgrade my uis in designer-qt4 and qmake-qt4, etc. I
> > get a compile error in the code as follows:
> >
> > ...
> > targets::targets() : QMainWindow()
> > {
> > mww = new Ui_Form();
> >
> > setCentralWidget(mww);
> > ...
> >
> > The error is that it cannot cast the Ui_Form to Widget*
> >
> > I get this whether I use qt3support or not, whether I create the ui from
> > new or open qt3 and save as qt4.
> >
> > 3. Looking at the header file produced by uic-qt4 within qmake-qt4/make,
> > etc. the class definition lacks the hierarchy so:
> >
> > ...
> > class targets
> > {
> >
> > public:
> > targets();
> > ~targets();
> > ...
> >
> > The header file is also really strange in another way. It has all the
> > controls okay, but misses out most of the names I give them.
> >
> > 4. If I run uic-qt4 manually it puts the hierarchy in (and all the
> > controls get named as well) and then the programme compiles correctly. It
> > then stops at the same line with a segmentation fault. Running with debug
> > suggests that the mmw object is okay.
> >
> > 5. I've tried taking out the Q3 objects and going to pure QT4 so that I
> > can run without qt3support, but it makes no difference.
> >
> > I'm not sure what is going on and so am finding it really hard to see
> > which way to go. My feeling is that it is something to do with 'features'
> > but I can't see anything wrong.
>
> Designer works much differently in Qt4 and in Qt3, but there is decent
> backwards compatibility support using uic3. In Qt4 pretty much every
> .ui needs to have some sort of subclass associated with it. If you used
> the old ui.h method to extend the functionality of your forms you will
> need to create subclasses of QWidget/Dialog that contain your extra
> functionality. Luckily uic3 can generate this code for you. This is a
> huge topic and I suggest watching the talk that I did at the 2006
> Trolltech Dev Days on porting from Qt3 to Qt4 for the full rundown on
> porting designer forms.
> http://www.trolltechvideo.com/video/day1/room_c/c_1_4/video.html
>
> Good Luck!
> --Justin
Hi
Thanks to you an Peter for your response. I've read the links and watched your
presentation - all very useful. I've made some progress as result.
I now get my ui appearing - always much more reassuring!
Although it appears, the implicit connections to slots are not being set up
and although the controls are available as public members, I still get
segmentation faults when I try to access them. I've now got:
HEADER
class targets : public Ui::cqb
{
public:
targets();
~targets();
protected:
void closeEvent(QCloseEvent *event);
public slots:
void on_pbNew_clicked();
};
namespace Ui {
class nstargets: public targets {};
}
IMPLEMENTATION
targets::targets(): Ui::cqb()
{
qDebug("gets here");
qDebug("the label is %s", (const char*)pbNew->text() );
}
void targets::on_pbNew_clicked()
{
qDebug("pbNew pressed");
}
Taking the second debug statement out gives me the first dbug message an the
ui is displayed with apparently working buttons, etc. just no debug from the
slot.
If I'm going to go to the effort of porting to QT4, it seems sensible to go
the whole way and use the new way of uis.
Thanks
Nick
--
[ signature omitted ]
Message 6 in thread
On Wednesday 09 April 2008 07:20:04 Nicholas Robinson wrote:
> On Tuesday 08 April 2008 18:18:34 Justin Noel wrote:
> > npr@xxxxxxxxxxxxxxxx wrote:
> > > Hi
> > >
> > > I've got two significant apps that I developed under QT 3.3. I would
> > > like to port one to QT4 and leave the other on QT 3.3 (only because it
> > > is too big and too mature to bother). So, I'm trying to port the other
> > > much smaller app. It's only got a few source files and half a dozen
> > > uis.
> > >
> > > I'm running into difficulties:
> > >
> > > 1. I can compile and run the KDevelop QT4 sample app without any
> > > problems so I think my installation (from Fedora 8 installation) is
> > > okay.
> > >
> > > 2. If I qt3toqt4 and upgrade my uis in designer-qt4 and qmake-qt4, etc.
> > > I get a compile error in the code as follows:
> > >
> > > ...
> > > targets::targets() : QMainWindow()
> > > {
> > > mww = new Ui_Form();
> > >
> > > setCentralWidget(mww);
> > > ...
> > >
> > > The error is that it cannot cast the Ui_Form to Widget*
> > >
> > > I get this whether I use qt3support or not, whether I create the ui
> > > from new or open qt3 and save as qt4.
> > >
> > > 3. Looking at the header file produced by uic-qt4 within
> > > qmake-qt4/make, etc. the class definition lacks the hierarchy so:
> > >
> > > ...
> > > class targets
> > > {
> > >
> > > public:
> > > targets();
> > > ~targets();
> > > ...
> > >
> > > The header file is also really strange in another way. It has all the
> > > controls okay, but misses out most of the names I give them.
> > >
> > > 4. If I run uic-qt4 manually it puts the hierarchy in (and all the
> > > controls get named as well) and then the programme compiles correctly.
> > > It then stops at the same line with a segmentation fault. Running with
> > > debug suggests that the mmw object is okay.
> > >
> > > 5. I've tried taking out the Q3 objects and going to pure QT4 so that I
> > > can run without qt3support, but it makes no difference.
> > >
> > > I'm not sure what is going on and so am finding it really hard to see
> > > which way to go. My feeling is that it is something to do with
> > > 'features' but I can't see anything wrong.
> >
> > Designer works much differently in Qt4 and in Qt3, but there is decent
> > backwards compatibility support using uic3. In Qt4 pretty much every
> > .ui needs to have some sort of subclass associated with it. If you used
> > the old ui.h method to extend the functionality of your forms you will
> > need to create subclasses of QWidget/Dialog that contain your extra
> > functionality. Luckily uic3 can generate this code for you. This is a
> > huge topic and I suggest watching the talk that I did at the 2006
> > Trolltech Dev Days on porting from Qt3 to Qt4 for the full rundown on
> > porting designer forms.
> > http://www.trolltechvideo.com/video/day1/room_c/c_1_4/video.html
> >
> > Good Luck!
> > --Justin
>
> Hi
>
> Thanks to you an Peter for your response. I've read the links and watched
> your presentation - all very useful. I've made some progress as result.
>
> I now get my ui appearing - always much more reassuring!
>
> Although it appears, the implicit connections to slots are not being set
> up and although the controls are available as public members, I still get
> segmentation faults when I try to access them. I've now got:
>
> HEADER
>
> class targets : public Ui::cqb
> {
> public:
> targets();
> ~targets();
>
> protected:
> void closeEvent(QCloseEvent *event);
>
> public slots:
> void on_pbNew_clicked();
> };
>
> namespace Ui {
> class nstargets: public targets {};
> }
>
> IMPLEMENTATION
>
> targets::targets(): Ui::cqb()
> {
> qDebug("gets here");
> qDebug("the label is %s", (const char*)pbNew->text() );
> }
>
> void targets::on_pbNew_clicked()
> {
> qDebug("pbNew pressed");
> }
>
> Taking the second debug statement out gives me the first dbug message an
> the ui is displayed with apparently working buttons, etc. just no debug
> from the slot.
>
> If I'm going to go to the effort of porting to QT4, it seems sensible to go
> the whole way and use the new way of uis.
>
> Thanks
>
> Nick
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
Hi
I went back to my original qt3.3 source and re-ran the entire port sequence
from scratch. I spotted a few warnings that I hadn't noticed before, got rid
of these and now have a working app in qt4 with qt3support.
Nick
--
[ signature omitted ]
Message 7 in thread
i don't see a call to setupUi() anywhere, which is bad.
also, in your header, you're missing the Q_OBJECT macro:
http://doc.trolltech.com/4.3/qobject.html#Q_OBJECT
Cheers,
Peter
Nicholas Robinson wrote:
> I now get my ui appearing - always much more reassuring!
>
> Although it appears, the implicit connections to slots are
> not being set up
> and although the controls are available as public members, I
> still get
> segmentation faults when I try to access them. I've now got:
>
> HEADER
>
> class targets : public Ui::cqb
> {
> public:
> targets();
> ~targets();
>
> protected:
> void closeEvent(QCloseEvent *event);
>
> public slots:
> void on_pbNew_clicked();
> };
>
> namespace Ui {
> class nstargets: public targets {};
> }
>
> IMPLEMENTATION
>
> targets::targets(): Ui::cqb()
> {
> qDebug("gets here");
> qDebug("the label is %s", (const char*)pbNew->text() );
> }
>
> void targets::on_pbNew_clicked()
> {
> qDebug("pbNew pressed");
> }
>
> Taking the second debug statement out gives me the first dbug
> message an the
> ui is displayed with apparently working buttons, etc. just no
> debug from the
> slot.
>
> If I'm going to go to the effort of porting to QT4, it seems
> sensible to go
> the whole way and use the new way of uis.
>
> Thanks
>
> Nick
--
[ signature omitted ]
