[PyKDE] Small bug, binding problem and kde2 thought

[Philippe Fremy]

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 ?



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.





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.

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).

That would also of course put more pressure on a full Kde 2 binding, but I
think having more people using it is a Good Thing (tm).

	Philippe