On Oct 7, 2008, at 12:54 PM, Phil Thompson wrote:
On Tue, 7 Oct 2008 11:10:57 -0400, Daniel Miller
<[EMAIL PROTECTED]>
wrote:
- I am moving to PyQt4 because I need to use some of the new features
(the Graphics View Framework, for one). If I did not need these new
features in PyQt4 I'd be content to stay with PyQt3.
...
Why should I rewrite an entire code base that is working fine and
does not need to be touched?
Obviously you shouldn't if it is meeting your current and anticipated
requirements.
It doesn't, see above.
PyQt3 has always maintained backwards compatibility, so has PyQt4.
PyQt3 is
not PyQt4. Likewise Qt3 is not Qt4. Granted, Trolltech produced a
Qt3=>Qt4
migration tool, but then they have orders of magnitude more
development
resources and charge a lot more money for their product.
You have a good point there. I should apologize for being so harsh. I
guess I'm just frustrated that I have to do so much work to get to
the point where I can actually start using PyQt4. I am really looking
forward to it...
Not at all. You talk about PyQt4 like it's some entirely new beast
sharing next to nothing with the old PyQt3. Maybe that's how the
underlying implementation looks, but the end-user functionality is
95% the same as it was in PyQt3--it still shows windows with widgets
on the screen, and users still interact with them in the same way
they did before. Adapting PyQt4 to the old PyQt3 API is not that
hard, it's just very tedious.
I'm beginning to see where you are coming from. Apart from the fact
that
there is tons more stuff in Qt4, which you probably haven't used if
you are
just trying to emulate Qt3, I found that my programming style
changed once
I became more familiar with Qt4. The model stuff just changes the
way you
think about an application's architecture.
I've started to experiment with the model stuff. I have a framework
similar to the Qt4 model API built around the old Qt3 table/listview/
combobox widgets, so it's mostly a matter of porting that framework
to use the new Qt4 API.
However, it's much less tedious to implement a single new version of
qt.QSettings based on PyQt4.QtGui.QSettings than to rewrite every
place in my application that happens to touch the QSettings API (for
example).
Every place? Surely you only use QSettings in one place?
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.
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?
Why should I start with a blank piece of paper when I already have
99% of what I need and it's all working correctly? You seem to think
there's value in rewriting code that is working perfectly. I see this
as a waste of my valuable time, which I could be spending
implementing new features.
And if your design is adaptable and able to take new user
requirements, and
new iterations of dependent technology easily then congratulations.
Except
it isn't, otherwise we wouldn't be having this conversation and you
wouldn't have calls to QSettings spread throughout your code.
Sorry, I picked a bad example; I don't have calls to QSettings
everywhere.
Especially
not in the transition to Python 3, as it would require us to test two
new things at the same time: Python 3 and PyQtX.
I know, that's what the thread on the mailing is all about. There
will be
the old API and the new API and both will be available,
simultaneously, for
Python2 and Python3. You choose which you want to develop against.
Great, that's what I was hoping would come out of this.
~~~~~~~~~~~
I tried to answer more of your questions, but the more I tried to
take them seriously the more it just seemed like you were trying to
blame my coding and design skills and not interested in the general
point that I've been trying to make. So in an effort to minimize name
calling and style bashing I'm going to stop here. Thanks a lot for
your hard work on PyQt up to this point.
~ Daniel
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
