On Thursday 07 September 2006 23:03:14 +0200, Simon Edwards wrote: > On Wednesday 06 September 2006 13:46, Hans-Peter Jansen wrote:
> > which reminds me that the official kdebindings3-python package of KDE > > 3.5.4 is _way_ behind the current state of affairs. > > True. One of the main problems here is that the copy in KDE bindings needs > to respect KDE's policies concerning binary compatibility between releases > and minor releases, while at the same time SIP and PyKDE have been on their > own schedule when it comes to things like breaking compatibility and > bumping library revisions. This independence is actually quite useful in other respects, particularly for SIP. > Which brings me to a topic that I've been wanting to talk about for a while > now: synchronising PyKDE with KDE itself and its schedule. What I would > like to see in the future is KDE shipping each time with a complete and up > to date version of PyKDE included. 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.) 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 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. 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. > To make this happen PyKDE development would have to be opened up more. Jim > has done a great job in the past developing and maintaining PyKDE, but to > do ensure synchronised releases with KDE it is going to take more people to > jump in and do what needs to be done before any given release. I'm willing > to pitch in to see this happen, and I see that Pete has already put his > hand up. ;-);-) I had hoped to spend more time on PyKDE, apart from recent visits back to old plugin projects, but I'm spending a lot of (free) time these days working to give PyQt4 more exposure. > Acceptance of languages like Python and Ruby for GUI development has > increased a lot in the last couple of years. Kubuntu for example, relies on > PyKDE as part of its base install. (It is needed for many of the > configuration tools, and in the next release for the thier new power > management applet). Python support as a standard, and first class part of > KDE looks like the next logical step to me to help continue this trend. 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. > PS. Just the other day I came across this for the first time > http://www.kumula.org/ . It's already in the list of known applications: http://www.diotavelli.net/PyQtWiki/SomeExistingApplications Feel free to add any more you find to that list. David _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
