KDE 4 (was: [PyKDE] PyQt 4 on openSUSE)

[Jim Bublitz]

On Friday 08 September 2006 12:11, Simon Edwards wrote:
> On Friday 08 September 2006 01:51, David Boddie wrote:
> > On Thursday 07 September 2006 23:03:14 +0200, Simon Edwards wrote:
> > While it would be nice to have ready made bindings for each new KDE
> > release, it's going to take some willingness on the part of the core KDE
> > developers to plan for this in their release schedules. (Maybe they
> > already do.)
>
> Well, the 3.5 release schedule looked like this:
>
> August 1st, 2005: Officially close of feature list
> August 25th, 2005: branches/KDE/3.5 is feature frozen
> September 5th, 2005: Message Freeze
> September 13th, 2005: Beta1 is prepared
> October 12th, 2005: Beta2 is prepared
> November 9th, 2005: Release Candidate 1
> November 29th, 2005: Targetted Release Date
>
> http://developer.kde.org/development-versions/kde-3.5-release-plan.html
>
> New APIs should be in place by feature freeze, which in this case leaves 3
> weeks till the first beta, the second beta was a good month after the
> first. 3 weeks isn't a lot of time to wrap and test a new API for the first
> beta, but there is quite a lot of time when you take the 2nd beta and the
> RC into account.
>
> Jim, I'm guessing that most of the time required for developing PyKDE goes
> into testing on the different platforms and distros? I think that a small
> group of people running different platforms and distros could help out a
> lot just by compiling PyKDE from KDE's SVN. Not to mention people like
> Adriaan de Groot who routinely recompile all of KDE's SVN on different
> platforms.

Right - mostly because the compiles take so long, and there are at least 5 
releases (3.0.x - 3.5.x) to test against. But see below (I used to go down to 
the '.x' level at one time).

> > Reading through the SIP files for PyKDE, you find lots of information
> > about the way the KDE APIs have evolved over time. If the bindings were
> > too closely
> > tied to some schedule where development was frozen too early before a
>
> You mean "too late before release" I assume.
>
> > release, there wouldn't be enough time to update the bindings to include
> > changes like these, unless the tools to generate the bindings could
> > manage it automatically. I think a staggered release schedule would work
> > much better.
>
> Releasing PyKDE *after* the main KDE release? We could request from KDE
> release group (is that the name?) that an API freeze be part of the normal
> feature freeze, or part of the string freeze. Or at the very least make a
> freezing APIs *strongly* recommended. Again it is hard to tell how it will
> work out w.r.t. the work. I don't know how super Phil's super code
> generation tool is. :)

I expect Phil's stuff is quite good, but I don't know how releasable it is or 
whether Phil wants to keep it proprietary (which I would understand 
completely). The other problem is likely that Qt uses "less" of C++ than KDE 
does, so Phil may not have addressed a number of issues. For example, there 
actually is somewhere in KDE a declaration like "unsigned long integer", 
whereas in Qt it would just be "ulong" or some macro everywhere, or the use 
of "explicit" with ctors. 

C++, even just h-files,  is a huge, variable and and somewhat ambiguous 
syntax. Phil has solved some of that by using gcc on the front end (I used a 
handwritten parser that understands both C++ and sip file syntax, since 
they're similar), but the backend still has to know how a particular piece of 
C++ syntax maps to sip syntax (if it even does).

In my case, it's been easier to let the tool do 99% of the work, grep for the 
errors I know occur, and patch those manually. Getting rid of that last 1% 
means a lot of slow debugging on big intermediate data dumps in my case, and 
part of the 99% (maybe another 1%) is achieved by effectively "#defining" out 
stuff in KDE that I can't parse.

Actually, if the code generation and versioning worked correctly, the 
back-testing wouldn't be as critical. Most of the errors that popup there are 
from versioning errors in the code generator. Now that I think about it, it 
would be possible to develop a tool to do that kind of testing without 
compiling, too.

So I'm thinking either I should fix what I have, or somebody should put 
together something better. Somebody who actually understands parsing and code 
generation could probably do a better job than I have.

 I really think an automated system that generates essentially perfect code 
(or knows when it can't) is quite possible - that, after all, is what sip 
does. There was a point around KDE3.3.x where I could have written a script 
to download KDE source and upload a PyKDE release with no manual steps in 
between.

The only real "hitch" is handwritten code, but there's much less of that now, 
the stuff from previous versions just transfers forward unmodified, and even 
that could be generated automatically about 99% of the time, as it's mostly 
cut and paste right now.

The other thing I don't want to overlook, though, is that KDE4 *may* introduce 
some early problems that either require programmer intervention (PyKDE still 
post-processes some of the code that sip generates to get around some 
problems - mostly QObject-related stuff), or require modifications to sip. So 
automation isn't initially a complete solution, but I think it would go a 
long way.

> > Although KDE 4 looks like it's starting to take shape, I can't believe
> > that there's not going to be a lot of flux in the APIs before they
> > stabilize into a form that provides the features that have been promoted
> > in various places. I don't think it's worthwhile synchronising just yet,
> > though it's possible that some groundwork could be put in for the future.
>
> oh, I'm not saying that we should fire up the compiliers right now for
> KDE4. ;-) As Sebas said, it is still a bit early. After Akademy it might be
> better.
>
> > We also need to work on increasing the range of developer tools available
> > to make it easier for people to develop and deploy Python applications on
> > KDE. This may come in the form of standalone GUI tools, or it may require
> > work to add support to existing IDEs, but it seems to me that it's
> > necessary.
>
> For KDE4 I want to see all of the extra dev support stuff that in "PyKDE
> Extensions" [1] rolled into PyKDE, along with support in CMake for building
> Python modules, sip stuff and being able to mix that with regular C++ based
> KDE development.

I, personally, won't go back to any of the Gnu "autotools" stuff, and I 
absolutely refuse to do anything that involves m4. Even if I had the time 
(and it takes almost more time than anything else), it's too ugly.  But that 
can be automated too - just not by me. Other than that, I'm a pretty nice 
guy. To be complete, I'm not a big distutils fan either.

In fact the original goal was to auto-generate the build system (configure.py) 
too, but I just never got back to doing that after some of the sip changes. 
Accomplishing that would overcome one of the big hurdles for people who want 
to develop other bindings, although Phil has made that a lot easier in recent 
years.

I'd have two problems with extending PyKDE much beyond what it looks like now. 
The first is just the size of the package and compile times. The second is 
that PyKDE as is, is pretty robust and gets away with minimal testing, while 
the extensions require more test/debug time. My opinion is that it belongs in 
a separate package.

But I don't have a problem with something taking what I do now and repackaging 
it somehow. either build method or extensions, similar to what putting it in 
the KDE CVS entailed. Or if someone wants to manage everything top to bottom, 
and will do it consistently over time, I'm not married to doing this either - 
just that no one else has ever volunteered to take it over. I'm still willing 
to participate to whatever extent is necessary.

> As for IDEs, we already have a very good and capable Python IDE in Eric3.
> Yes, conceptually and marketing wise it would be neater if Eric's
> functionality was also in one do-everything-IDE such as KDevelop. But Eric
> is here already, and I'm not going to complain about it. :)
>
> [1] http://www.simonzone.com/software/pykdeextensions/en/index.html
>
> cheers,