Hi, is it possible to get the source tar ball earlier? I'm asking because today for Ubuntu is Upstream Version Freeze and I want to upload it asap so we can be in sync with upstream?
Oh and the example code for KConfigSkeleton, I'll send you some example code, when I cleaned up my small test application for this. Inlcluding a simple and nice documentation. Regards, \sh On Thursday 19 January 2006 08:01, Jim Bublitz wrote: > I've just sent a new PyKDE snapshot (PyKDE-snapshot20060118) to Phil and it > should be available at http://riverbankcomputing.co.uk/snapshots/PyKDE as > soon as he has time to post it there (which is usually fairly fast, > depending on timezone differences). > > The 2 major changes are that I've updated KConfigSkeleton (detail below) to > handle scalars the way people have requested (more or less) and I've added > the kabc and kresources modules, which are kdelibs support for KAddressbook > classes. > > Help Request > ======== > > Both of the new additions were in response to requests from people on the > list. In turn, I'd like to request some help with those additions. The > KConfigSkeleton stuff needs both docs and a usage example program, the > KAddressbook stuff needs at least a good example of usage. I'd really > appreciate it if someone(s) could take some time to put some of that stuff > together (and also checkout the additions to make sure they work correctly > - I haven't actually tested any of this beyond compiling). > > I also need feedback on whether this snapshot builds on various systems - I > currently am only setup to test on SuSE so none of this has been tested on > Fedora, Mandriva, Ubuntu or Gentoo. I don't expect major problems. > > Next Release > ======== > > The next release will be PyKDE 3.15.0 or 3.15.1 - I've decided to sync the > PyKDE versions with the most recent KDE version supported, but I don't want > to go backwards to 3.5, so the 3.15.0 will have to stand for 3.5.0 until > KDE 4.0 support is available, which will be PyKDE 4.0. > > This Snapshot > ========= > > This snapshot brings PyKDE up to full KDE 3.5.0 support - it supports all > KDE versions from KDE 3.0.0 through 3.5.0. I've only backtested as far as > 3.2.x. It should also support Python >= 2.3.0, 4.0.x <= sip <= a fairly > recent snapshot (1/14?), and has been tested with gcc 3.3.1, 3.3.3 and > 4.0.1. As reported before, I can't get file concatenation to work with > either PyQt or PyKDE on gcc 4.0.1 - configure.py for PyKDE will > automatically switch to non-concatenated files for that gcc version > (otherwise it concatenates all the individual files for each module, which > saves about 80% of compile time). > > Since KDE 3.5.1 is just about ready to release, the actual PyKDE release > coming up may be 3.15.1 to include that. Either way, the offical released > version will be sometime in the next 2 weeks. > > KConfigSkeleton > ========== > > There were problems with the way KConfigSkeleton handled scalar types in > the addItem* methods and KConfigSkeleton::Item* class constructors. Each > now follows the pattern shown here using bool type as an example. For each > addItem* and Item* there could be two methods: > > PyKDE uses : ItemBool* addItemBool (const QString&, > bool&, > bool = 0, > const QString& = QString ::null > ); > > Patch used: ItemBool* addItemBool (const QString&, > bool = 0, > const QString& = QString ::null > ); > > > PyKDE uses: ItemBool (const QString&, const QString&, bool, bool = 1) > Patch used: ItemBool (const QString&, const QString&, bool = 1) > > In the addItemBool case, sip flagged the ambiguity between the signatures. > In the ItemBool ctor case, sip generated code for both versions, but the > second (original patch) version would be unreachable. > > Since part of the argument for including these is more "perfect" KDE > compatibility, I've chosen the first (4 argument "official KDE" signature) > version in each case. Because of the ambiguity, existing code using the > patch won't break in the sense that it won't run - it just works > differently. In both cases, existing code written like: > > x = addItem ("Name", False) > > or > > x - ItemBool ("Group", "Name", False) > > will set the item's value but *will no longer set the item's default > value*. > > > kabc and kresource > ============ > > Both of these modules are essentially complete. kabc is missing the global > functions in ldifconverter.h, kresource is missing the Manager class. Both > will probably get picked up in a future release. I think the problem with > the ldifconverter stuff is just missing header info. The Manager class is a > fairly involved template class and I didn't want to hold up the release > working this out. PyKDE bindings for Manager will not be general in the > same sense a C++ template class is - they'll be tied to a concrete use, > like kabc - other uses of Manager will require additional code in PyKDE. > > Other changes > ========= > > kjs support was dropped some time ago, and kdesu support a few snapshots > back. I don't plan on making either of those part of the official PyKDE. I > haven't heard any complaints. > > I've done some code cleanup and added support for a few methods probably > nobody uses (mostly methods involving QPair as an argument or return > value). > > Tomorrow I'll be driving through Cascade mountain passes and the Columbia > River Gorge to Portland and back (12-14 hours altogether, longer if a lot > of snow in the passes), and Friday I'll be putting the hydraulic pump for > the end loader back on my tractor (I hope) - too greasy (and aching, most > likely) to do much computing. Somewhere in there I'll probably have to make > some money too. > > I will, however, get to any bug reports and related stuff as soon after > that as possible. > > Jim > > _______________________________________________ > PyKDE mailing list [email protected] > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
