On 07.10.08 14:47:00, Daniel Miller wrote: > Well, yes of course. Sorry for picking a bad example. How about > QSplitter, QPushButton, QProgressBar, QPopumMenu, etc. Those are > definitely used in many places, and the API for each of them changed. I > realize this is not your fault--it was a decision made by Trolltech. > However, I feel like they did more to help their users migrate old code > bases to Qt4.
They didn't. The qt3to4 tool is a joke when you try to migrate a real-world large codebase, it barely provides a starting point. Also it forces you into the Qt3Support classes, code thats barely maintained by TT - they only fix the worst bugs in those parts. So, the C++ migrators don't really have more help than the PyQt4 users. >>>> Note that I wouldn't call the Q3Support classes a compatibility >>>> layer. >>> >>> I agree. In a C++ app it might be possible (even simple?) to do >>> global find/replace ... >> >> You are seriously suggesting that PyQt4 should include a full >> emulation of >> the PyQt3 API??? > > Why not? Is it too much to expect a widely used library to have backward > compatibility between versions? Yes, if there's basically just 1 person doing the work and he's expected to offer an opensource version and a not-that-expensive commercial version. Seriously, a complete compatibility layer is a _huge_ amount of work. If Phil would've done that, we might still be waiting for the PyQt4.1 release. Andreas -- A visit to a strange place will bring fresh work. _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
