Qt-interest Archive, April 2007
porting qt3->qt4 with backwards compatibility
Message 1 in thread
I am trying to port QT3 app to QT4, while keeping compilability with
qt3. Many classes have been renamed (QListView -> Q3ListView), so I
created some "compatibility" header like this:
#if defined(QT_VERSION) && QT_VERSION >= 0x040000
// QT4 or newer
#define QT4 1
#define Q_ListViewItem Q3ListViewItem
#define Q_ListView Q3ListView
...
#else
// QT3
#define QT3 1
#define Q_ListViewItem QListViewItem
#define Q_ListView QListView
...
#endif
I include it in every relevant file and use Q_ListView where QListView
(qt3) or Q3ListView (qt4) should be used. It works fine .... till it
get to the MOC, signals and slots. Unfortunately, stuff inside SIGNAL
and SLOT macros will not be preprocessed, so I have to use #ifdef
QT4/endif in few places. What is worse, MOC seem not to understand
this compatibility header, so MOC puts the unpreprocessed types (like
"Q_ListView") into moc_*.cpp files, breaking the slots too
Is there some better option than putting #ifdef/#endif around each
slot/signal function declaration in (almost) all files?
Have anybody encountered this problem? Is there some more elegant
solution to this?
Martin Petricek
--
[ signature omitted ]
Message 2 in thread
On 22.04.07 22:19:40, BH wrote:
> I am trying to port QT3 app to QT4, while keeping compilability with
> qt3. Many classes have been renamed (QListView -> Q3ListView), so I
> created some "compatibility" header like this:
>
> Is there some better option than putting #ifdef/#endif around each
> slot/signal function declaration in (almost) all files?
No.
> Have anybody encountered this problem? Is there some more elegant
> solution to this?
Yes: Break backwards compatibility. Either maintain your application as
two versions, one for Qt4 and one for Qt3 or only maintain either one of
the versions. This is IMHO the only sensible way to go, ifdef's all over
the code make the code unreadable, unmaintainable and will get you in
trouble sooner or later.
Also there are various things that fundamentally changed between Qt3 and
Qt4 and using the Qt3 support classes you can't benefit from them.
Oh, one last thing: If you're really lucky the qt3to4 tool may be able
to port your application, then you can add this as a pre-make step and
thus a user can decide to either build against qt3 or qt4 by some
configuration option (which would run qt3to4 or not).
Andreas
--
[ signature omitted ]
Message 3 in thread
I aggree with Andreas. The preprocessor route is a tough path to follow.
One of the strengths of Trolltech, I believe, is that they are not afraid
to break compatabilty between major releases. With that in mind, it would
seem futile for us to try and maintain compatability.
I've used namespace aliasing before to some degree of success, but here's
the upgrade path I settled on:
First, make one .pro file and put all your sources in one directory. Make
the .pro file as simple as you can. Then run the qt3to4 tool. Get it to
run again. Then one by one remove the q3* headers. Then eventually you
can remove the q3 library reference from the .pro file.
Mark
On Sun, Apr 22, 2007 at 10:54:41PM +0200, Andreas Pakulat wrote:
> On 22.04.07 22:19:40, BH wrote:
> > I am trying to port QT3 app to QT4, while keeping compilability with
> > qt3. Many classes have been renamed (QListView -> Q3ListView), so I
> > created some "compatibility" header like this:
> >
> > Is there some better option than putting #ifdef/#endif around each
> > slot/signal function declaration in (almost) all files?
>
> No.
>
> > Have anybody encountered this problem? Is there some more elegant
> > solution to this?
>
> Yes: Break backwards compatibility. Either maintain your application as
> two versions, one for Qt4 and one for Qt3 or only maintain either one of
> the versions. This is IMHO the only sensible way to go, ifdef's all over
> the code make the code unreadable, unmaintainable and will get you in
> trouble sooner or later.
>
> Also there are various things that fundamentally changed between Qt3 and
> Qt4 and using the Qt3 support classes you can't benefit from them.
>
> Oh, one last thing: If you're really lucky the qt3to4 tool may be able
> to port your application, then you can add this as a pre-make step and
> thus a user can decide to either build against qt3 or qt4 by some
> configuration option (which would run qt3to4 or not).
>
> Andreas
>
> --
> Your analyst has you mixed up with another patient. Don't believe a
> thing he tells you.
>
> --
> 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 4 in thread
Well, I have tried a bit and almost half of the code is qt4-compilable
with minimal changes, while keeping compatibility. Sometimes things
can be changed so they work both in qt4 and in qt3 (like the
replacement of QVbox with QFrame anf QVBoxLayout recommended in the Qt
docs), sometimes adding forgotten include help ....
My main reason to upgrade is QSA (which is .. ahem ... slow and have
some API deficiencies resulting in huge memory leaks ultimately) The
deficiencies are fixed in qt4.3 (QtScript...), but 4.3 is still beta.
So in my case I am porting from qt3 to qt 4.3 (qt4.2+QSA still have
the bugs I want to avoid, so porting to anything between qt4.0 and
qt4.2 is a bit pointless for me). But most linux distros have still
qt4.2 or 4.1 - thats why I want still the backwards compatibility,
almost nobody have qt4.3 now, but qt3 is common (though a bit
obsolete). Once qt with Qtscript will be stable and widespread
enought, qt3 support will be unnecessary in my app.... but first
non-beta release of qt4.3 is I think july 2007 and before it is
adapted in stable versions of most major distros, it may be about end
of year or so .... till then, I need qt3 compatibility.
Since most problems are due to QListView(Q3ListView), I think i'll try
sticking in some preprocessor . Is there some possibility to add some
general rule like $source.cc -> preprocessed_$source.cc in the .pro
file, or do I have to preprocess the project file as well? :)
Another option would be backporting QTscript to qt3, but I want to avoid this...
Martin Petricek
On 4/23/07, Mark Beckwith <mark@xxxxxxxxxx> wrote:
> I aggree with Andreas. The preprocessor route is a tough path to follow.
>
> One of the strengths of Trolltech, I believe, is that they are not afraid
> to break compatabilty between major releases. With that in mind, it would
> seem futile for us to try and maintain compatability.
>
> I've used namespace aliasing before to some degree of success, but here's
> the upgrade path I settled on:
>
> First, make one .pro file and put all your sources in one directory. Make
> the .pro file as simple as you can. Then run the qt3to4 tool. Get it to
> run again. Then one by one remove the q3* headers. Then eventually you
> can remove the q3 library reference from the .pro file.
>
> Mark
>
> On Sun, Apr 22, 2007 at 10:54:41PM +0200, Andreas Pakulat wrote:
> > On 22.04.07 22:19:40, BH wrote:
> > > I am trying to port QT3 app to QT4, while keeping compilability with
> > > qt3. Many classes have been renamed (QListView -> Q3ListView), so I
> > > created some "compatibility" header like this:
> > >
> > > Is there some better option than putting #ifdef/#endif around each
> > > slot/signal function declaration in (almost) all files?
> >
> > No.
> >
> > > Have anybody encountered this problem? Is there some more elegant
> > > solution to this?
> >
> > Yes: Break backwards compatibility. Either maintain your application as
> > two versions, one for Qt4 and one for Qt3 or only maintain either one of
> > the versions. This is IMHO the only sensible way to go, ifdef's all over
> > the code make the code unreadable, unmaintainable and will get you in
> > trouble sooner or later.
> >
> > Also there are various things that fundamentally changed between Qt3 and
> > Qt4 and using the Qt3 support classes you can't benefit from them.
> >
> > Oh, one last thing: If you're really lucky the qt3to4 tool may be able
> > to port your application, then you can add this as a pre-make step and
> > thus a user can decide to either build against qt3 or qt4 by some
> > configuration option (which would run qt3to4 or not).
> >
> > Andreas
> >
> > --
> > Your analyst has you mixed up with another patient. Don't believe a
> > thing he tells you.
> >
> > --
> > 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/
> >
>
> --
> Mark Beckwith (mark@xxxxxxxxxx)
>
> --
> 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 5 in thread
On Mon, Apr 23, 2007 at 12:23:54PM +0200, BH wrote:
> non-beta release of qt4.3 is I think july 2007 and before it is
> adapted in stable versions of most major distros, it may be about end
> of year or so .... till then, I need qt3 compatibility.
Ok, the real issue is distribution. If this is the case, just distribute
the Qt 4.3 or whatever libraries along with your program. Check out:
http://silmor.de/30
for a nice little discussion about this and "wrapping binaries". This
method works great.
--
[ signature omitted ]
Message 6 in thread
> > non-beta release of qt4.3 is I think july 2007 and before it is
> > adapted in stable versions of most major distros, it may be about end
> > of year or so .... till then, I need qt3 compatibility.
>
> Ok, the real issue is distribution. If this is the case, just distribute
> the Qt 4.3 or whatever libraries along with your program. Check out:
>
> http://silmor.de/30
>
> for a nice little discussion about this and "wrapping binaries". This
> method works great.
Well, stuffing qt4.3 sources in the tarball and growing it from 3mb to
45mb may not be the best idea ... this may work with commercial apps
if you target one or few systems, but probably not with opensource
supposed to run also on systems and architectures I have no access to
(I may not be able to create myself powerPC binaries for BSD, yet the
program may still run on it)
If you multiply architectures (x86, amd64, sparc, powerpc .....) with
systems (various BSD's, various Linuxes, Solaris, Cygwin ...) you can
get ridiculously large number of various binaries ....
I wondered about separating Qtcript from Qt4.3 and modifying it to run
also with qt4.0-qt4.2 ... (qtscript is relatively small, so it may be
reasonable to stuff it in the source tree). This will solve issue with
requiring too recent Qt. But if Trolltech have made some specific
changes in qt4.3 to accomodate for QtScript, this may be very hard or
impossible. Can any insider shed more light on feasibility of doing
this?
Martin Petricek
--
[ signature omitted ]
