[PyKDE] Sugestions for PyQt4

[Giovanni Bajo]

Eric Jardim <ericjardim at gmail.com> wrote:

> Hi, I want to make some sugestions for PyQt4. It will be good if people
> comment them, as some of this ideais may be not good or just imcomplete.
In
> advance, sorry if my english is bad. I could also speak Japanese if you
want

I would like to state that PyQt (both 3 and 4) are currently just plain
wrappers against the C++ interface. They do not pythonize the interface in
any way. There are many things that could be done to improve the Qt API,
were Qt written in Python. But Qt is written in C++, and PyQt goal is to
expose Qt to Python. And I think it's a valuable goal.

As I said elsewhere, I believe this kind of improvements belongs to a
separate wrapper, such as PyPyQt built on top of PyQt. Others would prefer a
PyQt compilation switch or something like that.


> - No more QStrings and QByteArray: As Python have good support for unicode
> strings, there is no need for this objects appear in Python. All
conversions
> should be done internally and automatically.

This was discussed at length (at least for QString) in the mailing list.
Phil empowered QString so to expose the buffer interface and thus making
them duck-typable with Python strings everywhere. This is a very good
compromise IMO. Anything else should be done elsewhere. Also notice that
QString is mutable, and any unicode <-> QString conversion causes an
additional copy (which might cause performance issues in some side case).


> - Better support for the "tr" function:  As was sugested before in the
list,
> the "tr" function could be installed as a __builtins__ function. We can
use
> the stack to determine the context, with no need to sacrifice pyuic4 or
> pylupdate4.

How do you plan to modify pyuic4 so to infer the context without a preceding
"self."? It's going to be non-trivial.


> - "Pythonic" Qt properties: instead of using things like: "isEnabled()"
and
> "setEnabled()", properties could be acessed like python real properties, I
> mean, just "enabled". The functions could still be mapped anyway.

Alas, we can't do this *and* preserve C++ compatibility, because of the way
getters are usually called (like color()). So either we have a property
(.color) or a getter (.color()), we can't have both. In this case, this
change would break compatibility.

Also, another suggestion that was made in the past was to accept properties
in the constructor as keyword arguments (QWidget(parent, color=Qt.white,
width=100)). This could be made without breaking compatibility *for now*,
but it could be an issue if PyQt/SIP start supporting keyword arguments in
function calls.


> - Dynamic metaobjects:
> - The new Signal, Slot, Property idom:
> With all this changes, it should be nice to define the a way to declare
our
> QObject classes extensions. My sugestion is the simples as possible:
>
> from PyQt4 import *
> from PyQt4.QtCore import *
> from PyQt4.QtGui import *
>
> class MyWidget(QWidget):
>     # how to define a slot
>     def aSlot(sender, text):
>         ...
>     aSlot = QSLOT(aSlot, 'QObject, str')
>
>     # how to define a signal
>     def aSignal(message):
>         ...
>     aSignal = QSIGNAL(aSlot, 'str')
>
>     # how to define a property
>     def pSet(value):
>         ...
>     def pGet():
>         ...
>     p = QPROPERTY(pGet, PSet, ...)  #look: p is a Qt and Python property!

It could make sense if they are optional (and needed only for interaction
with the Designer. How should a signal function be defined, though? Maybe
it's better to just use a syntax like "foo = QSIGNAL()". As for the slot
decorator, there is a similar decoratory already that it's used to
disambiguate overload resolution. So it's currently possible to mark slots.
It might make sense to reuse this decorator instead of creating a new one.

> - Smart flexible connections
> Why should I connect this:
>>>> connect(a, SIGNAL('aSignal(QObject*,const QString&, int)'), b.aSlot)
>When I can do this: connect(a, SIGNAL('aSignal(QObject, str, int)'),
>>>> b.aSlot)


I think there are techinical issues, as Phil already rejected this. I don't
know the details.

> Hope you enjoy and this be useful for the PyQt project.

Thanks for the input!
-- 
Giovanni Bajo