[PyKDE] PyKDE2 Announcement

[Bruce Sass]

On Sat, 9 Jun 2001, Jim Bublitz wrote:
> On 09-Jun-01 Bruce Sass wrote:
> > On Sat, 9 Jun 2001, Jim Bublitz wrote:
>
> > So why not make what is done available as an alpha pre-release?
<...>
> I'm all in favor of "release early/often", but I have some pride about what
> gets released too. And I think it's a bad idea to release too early, which this
> is right now.

OK

> > I guess that depends on what one wants to do with PyKDE...
> > 95% is significant, surely that is enough for us end-users to start
> > compla^H^H^H^H^Hhecking it out.  ;)
>
> When you see how long it takes to compile (KDE2 is big), you won't even have to

Ya, I know, it took me 6 days to compile KDE2beta releases, really.

> check out the actual code to start complaining :)
>
> Part of the 5% is what requires some of the hand editing of generated
> code (problems with abstract classes, and possibly a SIP problem - not sure),
> but it's usable and can probably go out well before it's completed. I guess my
> preference is that people be able to build it easily, which should be possible
> in a few weeks. If it were just a matter of a few functions commented out, I
> wouldn't care (and in fact that will probably be the case anyway).

A few weeks sounds much better than a couple of months, 'cause we have
all seen how proposed release dates tend to slip. ;)

Is the manual hacking needed scriptable?


> > Hmmm, when did KDE start doing a binary distribution.
>
> Binary as opposed to source RPM's.

Someone other than KDE builds the binary and source _packages_, and
the packagers will use release tarballs or CVS...

> > I think anyone
> > wanting to play with a pre-PyKDE2 will know how to get the -dev (or
> > -devel) binary packages for KDE2 provided by the distribution they
> > use.
>
> I don't believe the .h files in question are in the dev packages (unless I'm
> missing one) - that's the problem. You need the complete source, which not
> everyone will have (I never used to bother with it), and which complicates the
> automake stuff, since even people who do have the complete src (tarball or RPM)
> won't necessarily have it in a well-known location. My inclination is to
> include the extra .h files in the PyKDE2 distribution.

...so there is really no way to know what is included in them, and
which one(s) will be needed.  By including what you think are "extra"
header files from KDE2 you are biasing the PyKDE2 source towards a
specific distribution (the one you use) and a specific release of KDE2
(the one the distribution used for the release of it you are using).

I Think...

...more complicated "automake stuff" that provides a consistent build
process across platforms is better than risking getting into a
situation where building on <this> version of <that> system is a
no-brainer, but ya gotta do <this that and the other thing> to build
on a significant number of the other platforms PyKDE2 will run on.
Not only is it doing the ones who get the no-brainer setup a
dis-service (IMO)... wouldn't it make your job a little tougher if the
simpler automake stuff resulted in bug reports from people trying
out different customised "hoops" 'til the act comes together (so to
speak).

...you should not worry about this, let the packagers for the various
distributions sort it out via whatever dependencies mechanisms they
have to work with.  In other words, forget about RPMs and DEBs, do a
source tarball that depends on other source tarballs -- if some
distribution's developer packages are broken with respect to the
header files provided, it'll get fixed.

> I've only had broadband for a little over a month, so I'm still sympathetic
> with those people who have slow links - KDE source is fairly large for some of
> us, especially just to pick up a half dozen missing header files.

How about making a separate tarball for this stuff, clearly marked
with which version(s) of which package(s) for which distribution(s) it
is needed with; noting that the relevent package maintainers have
been informed of the problem, and it would be a good idea to use
newer packages if they are available 'cause this could affect the
building of other KDE aware apps. <0.5 wink>

> Phil has done an amazingly good job with SIP (IMHO) and continues to make
> improvements, so I don't expect there to be much in KDE2 that won't be
> accessible from Python.

All I know is that it worked from the start (PyKDE-1, once I installed
the proper -dev packages ;), and I've had no problems since.  If I
(with no C++ and only K&R C knowledge and at the time a relative
newbie to Python) can rewrite the old PyQt(-1.xx) tutorials to jive
with the new Qt-2.x tutorials, and end up with virtually identical
results as Phil had 2-weeks earlier... someone is doing something
right, and the prime suspect is Phil.


> >> Qt2.3.0 and KDE 2.1.1 or 2.1.2. The KDE ClassRef documentation is also
<...>
> > Why not Python 2.0 and 1.5.2?
<...>
> I agree here too - it annoys me to have to d/l lots of other stuff for no
> good reason. Python >= 1.5 should work, as long as you compile with that. I
> don't know of anything being done that requires Python 2 - Phil can probably
> provide a more reliable answer.

I'm running a testing/unstable Debian system and have access to
developer built packages for: Python 1.5.2, 2.0, and 2.1;
post-KDE-2.1.1 (with 2.1.2 libs) and KDE2.2; Qt 2.3 and 3.0.

I figure that if PyKDE2 was available now I would be able to build
against any reasonable combination of the three, without too much
trouble.  PyQt has been pretty good about this kinda thing, I never
got into PyKDE enough to see how it coped with versions of KDE it
didn't really know about.  [ If that sounds a little over-optimistic,
it is Phil's fault for raising my expectations. :) ]

So, if I got it right, my expectations could be at least realizable in
a couple of months, and alpha quality stuff may be around in less than
half that.


- Bruce (hurting for PyKDE2 worse than he was for KDE2...)