[PyKDE] Small bug, binding problem and kde2 thought

[Phil Thompson]

Philippe Fremy wrote:
> 
> Hi,
> 
> I'm working on a small game where I have a bunch of sprites moving around.
> The sprites are rectangular pixmaps with no mask. So I need to use a
> QCanvasSprite to "support" them.
> 
> QCanvasSprite has only one constructor that takes a QCanvasPixmapArray object
> as arg. So, I need to build a QCanvasPixmapArray.
> 
> The arguments of QCanvasPixmapArray are either a QString containing a file
> pattern of files to load or a QList of Pixmap with a QList of QPoint.
> 
> I am creating my Pixmaps on the fly, so I don't have a File Pattern to provide.
> But (and here is the point) the second constructor hasn't been implemented.
> Checking the sip file reveals indeed a :
>         QCanvasPixmapArray();
>         QCanvasPixmapArray(const QString &,int = 0);
> //      QCanvasPixmapArray(QList<QPixmap>,QList<QPoint>);
> 
> I wonder why this constructor was left out. The only way I now have to build my
> QCanvasSprite seem to be : write my pixmap to a tmp file and then read it with
> QPixmapArray( QString ) !!!
> :-((
> 
> Or dit I miss something ?

It's not implemented because of the use of templates and because I'm
lazy. Would being able to pass a Python list of QPixmaps and a Python
list of QPoints be OK?

> By the way, I don't think this should happen:
> philippe at grayswandir:~/python/test > python
> Python 1.5.2 (#1, Nov 13 1999, 12:17:58)  [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import qt
> >>> qt.QString()
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> TypeError: repr not string
> >>>
> The problem only exists for empty QString that one want to print.

The problem with this is the behaviour of repr(). The standard
convention in PyQt is that NULL translates to None and vice versa -
which is what is happening. It could display an empty string instead -
but that might imply that a null QString and an empty QString were the
same - which they are not.

> Small thought about kde 2.0 and underlying python bindings :
> 
> Kde 2 has a huge base code, so developing a binding for the whole thing
> is crazy, especially if you want to have all the technologies working (Dcop,
> kpart, ...). It will take a really long time to have all this done.

I will certainly be prioritising the KDE2 support and it will only
include those classes that make sense with Python. I don't think it will
be as bad as you might expect.

> But it bothers me that I can't integrate my application at all into kde 2. I
> think it should be possible to just have the minimal integration available.
> What is really required to make an application Kde 2.0 aware (or Kde 2.0 alike) ?
> 
> - KApplication
> - KMainWindow
> - KConfig to store the configuration
> - .desktop file but that's already ok
> - Standardized dialogs : KMsgBox, KAbout, KFileDialog, KFontDialog and a few
>   others
> 
> The two others I'm not sure about are:
> - KAccel so standardize short-cuts
> - KAction instead of QAction ?
> 
> PyQt is ok for all the remaining things, as long as you don't want the great
> new technologies.
> 
> So, what about developing a tiny Kde 2.0 binding with just these things ? That
> would allow integration of still-PyQt-but-want-to-be-PyKde programs into Kde.
> That would also attract more developers to PyKde because it would now be
> in the move (although in practise, they would more do PyQt code). And more
> developers means more help for the binding. I must say knowing that my
> application would be only Qt2 aware and not Kde2 has discouraged me to start it
> with Python (but not long as I then gain the windows portability).

The first release of PyKDE for KDE2 will be a tiny binding. All I will
do is to do the minimum work to upgrade PyKDE for KDE1 to get it to work
with KDE2.

What would be a real help to me is if people gave me a list of the KDE2
classes they want implemented sooner rather than later.

Phil