[PyKDE] branching, PyKDE major versions

[Phil Thompson]

>
> On Jul 17, 2005, at 11:36 PM, Phil Thompson wrote:
>
>>> I am curious. I have noticed, or it has been brought to my attention,
>>> that it it has become a bit unusual that the PyQt source package
>>> supports all versions of qt, back to 2.3. In the interest of writing
>>> sip code for qt 4, Is there any particular reason why all qt versions
>>> are supported in one package? wouldn't it be a good idea to branch
>>> the project at least at major versions?
>>>
>>
>> PyQt supports all versions of Qt back to 1.44. All versions are
>> supprted
>> in one package because it's easier for me to do it that way. There
>> was a
>> time when the code generated by SIP supported all versions of Qt
>> (through
>> millions of #if's) but that was in the days when I didn't
>> distribute the
>> .sip files.
>>
>>
>>> It looks to me like there are enough symantic differences in qt4 that
>>> now would be a good time to consider such a change. The reason I'm
>>> bringing this up is that the thought had crossed my mind to help in
>>> writing some of the sip code for qt4, but having looked at the <=3
>>> code (size, version compensation, and I'm a little reluctant to. If
>>> we were looking at schlepping sip code from pyqt3.x to  pyqt4.x, and
>>> writing appropriate new code, it would look a little more attractive.
>>>
>>
>> However, PyQt4 will be different as it is being written using
>> something
>> called MetaSIP. This is a GUI tool (written using PyQt of course) that
>> parses the C++ header files and creates a database of the whole
>> API. It
>> allows you to enable/disable individual classes/functions of the API,
>> annotate individual arguments etc, and spits out .sip files. It can
>> also
>> compare different versions of an API and generate the necessary %If
>> directives.
>>
>
> Good grief. The GUI will make it more attractive, the parser could
> push sip straight into SWIG's shoes. wow.

The parser is GCC-XML.

>> I'm not going to bother moving PyQt3 to MetaSIP as Qt 3.x is now very
>> mature and it's just not worth it. However, I do anticipate that
>> PyQt4,
>> PyQt5 etc will all be built from the same MetaSIP database.
>
> What are the toughest bottlenecks going be for finishing MetaSIP?
> Will the only work for PyQt4 be modifying the MetaSip "output"? Is
> this a project that could use some help? If so, what kind?

MetaSIP is finished - I've used it for developing proprietary bindings for
commercial customers. (Actually Qt4 needs a slight change because of it's
complicated header file structure.)

The biggest bottleneck for PyQt4 is pyuic4. Previously, with each major Qt
release (ie. Qt v2, v3) I would abandon the previous pyuic and create a
new one based on the new uic. This obviously introduced a lot of
regressions. Also there have been discussions on this list about wanting
extra Pythonic features from pyuic - being able to import it as a module
for example.

I would like to see a pure Python implementation of pyuic that can be used
standalone (as now) or as a Python module. Torsten was doing something in
this area but I'm not sure how far he has got. While this would take
longer to implement in the short term, it wouldn't get thrown away when
Qt5, Qt6 were released.

Which approach I eventually take will depend on how much time I have. On
the other hand this is something that is self-contained and (apart from
actually being able to execute the generated code) independent of the rest
of PyQt4 development. So it's something that somebody else could run with
quite easily.

Phil