[PyKDE] PyKDE uses qt2 compat header

[Andreas Pakulat]

On 24.04.06 15:50:37, Jim Bublitz wrote:
> On Sunday 23 April 2006 05:28, Andreas Pakulat wrote:
> > Hi,
> >
> > the latest PyKDE snapshots includes qlist.h in various places, however
> > this is a "deprecated" header file, the correct one to use is
> > qptrlist.h (which is included from qlist.h). I stumbled over this because
> > Debian has split the compatibility headers into a separate package which
> > is not installed here. Would be cool to have this fixed as it's really
> > only a sed 's/qlist.h/qptrlist.h/'
> 
> I only found 3 occurrences. Two appear to be obsolete %MappedTypes which are 
> no longer referenced anywhere else (deleted those) and the third I fixed. If 
> you find more, let me know

I count 4 here:

andreas at morpheus:~/compiling/python/PyKDE-snapshot20060422>grep -r qlist.h *
sip/kdeui/klistview.sip:#include <qlist.h>
sip/kfile/kfileviewitem.sip:#include <qlist.h>
sip/kfile/kfilebookmark.sip:#include <qlist.h>
sip/khtml/khtmlview.sip:#include <qlist.h>

> > Also I noticed a few warnings about inclusion of internal headers from
> > KDE in the kdeprint-part. 
> 
> Yes - there may be dependencies elsewhere in kdeprint that require these, but 
> I haven't checked. At any rate, the headers are included in the standard set 
> of headers KDE distributions provide (for example, in /opt/kde3/include on 
> SuSE - not just in kdelibs source), or they wouldn't get picked up 
> automatically (I don't provide the header files in question).

Just wanted to mention it as I wrote a mail anyway...

> > And a few warnings about returning addresses 
> > from temporary objects:
> > sip/kmdi/kmdichildfrm.sip: In function ‘PyObject*
> > convertFrom_QDict_0500QWidget_FocusPolicy(void*, PyObject*)’:
> > sip/kmdi/kmdichildfrm.sip:223: warning: taking address of temporary
> 
> There are lot more than that - also "possibly unitialized variable" warnings. 
> As far as I've checked out, the code is correct - I haven't tested these in a 
> while (haven't kept unit tests up to date), but I don't think they cause a 
> problem since all of the pointers are only used locally.

Same as above, just wanted to mention it...

Andreas

-- 
Beware the one behind you.