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, _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
