|
| This Week... |
|
Optimisations in KDE startup services. amaroK gains CD Ripping functionality through the audiocd:/ kioslave. KDE 4 changes: Phonon, the KDE 4 multimedia service sprouts the beginnings of a Xine backend. Reorganisation of the KDE-PIM module (KPilot and KMobile leave the module, respective destinations extragear/pim and playground/pim; Kandy, Kitchensync and Multisynk also removed). Kodometer removed.
|
Stephan Kulow outlines the upcoming development schedule for the KDE 3.5 branch:
|
Hi!
As the commit freeze was a bit lifted, I would like to announce that I'm going to tag KDE 3.5.3 on may 23th and to give the editors and translators some room to catch up with the changes I declare the KDE 3.5 branch frozen as of may 2nd (as in next tuesday).
This freeze will be active till I announce that the tagging is done.
Greetings, Stephan
|
|
The 3.5 release has been developed in a slightly unusual manner, with some new features allowed in after the 3.5.0 release. This is a change of pace from previous releases, where only bug fixes and translations were allowed after this period, and takes into account the unique position of 3.5 as the last of the KDE 3 series, with a neccessary longer-than-usual wait until the next major release - KDE 4.
Automated code quality checks continue to pay dividends in the form of a wealth of memory leak and potential crash fixes (see commits referencing Coverity ID, or CID, numbers). Dirk Mueller has been a big mover in this, with supporting efforts by Stephan Kulow, and though this work isn't highlighted in any statistics, all users will be able to feel the effect of this work in future releases. Although the main target for these fixes has been /trunk (KDE 4), the most serious and beneficial ones have been backported to the 3.5 branch. These events mean that the KDE 3.5.3 release in 23 days time will be one you won't want to miss.
|
Cornelius Schumacher proposes another kde-pim reorganisation, though of a different kind, encompassing the extensive libraries in that module:
|
The kdepim module has grown to an impressive size. After kdebase and kdelibs it's the third biggest KDE module and it's becoming more and more complex to work on kdepim because of the sophisticated intra-module dependencies.
Additionally there is some code in kdelibs which is closely associated to kdepim in kdelibs (kresources and kabc). That this code is in kdelibs, but other similar code like libkcal is not can only be understood by historical reasons.
To make things worse there is some code from other modules depending on kdepim (e.g. the kbugbuster kresource from the kdesdk module) violating the rule that modules shouldn't have other dependencies than kdelibs.
To resolve these problems I propose to create a new module "kdepimlibs" in SVN which contains the major libraries from kdepim and the kdepim-related libraries from kdelibs.
The new module would follow the same policies and release schedules as kdelibs, and other modules would be allowed to depend on it. So it basically would be a controlled extension and modularization of kdelibs to the pim space, but by being a separate module we would also have a clear boundary to deviate from the kdelibs policies or release schedules, if the need for this arises. At the moment I don't see such a need, though.
The module "kdepimlibs" would tentatively contain the following components:- kresources (the generic resource framework (this will be superceded by Akonadi at some point in time))
- kabc (the KDE address book library)
- libkcal (the KDE calendar library) akonadiserver, libakonadi (the upcoming PIM Storage Service)
- libemailfunctions (the infamous attempt to create a shadow kdelibs under a most obscure name and by highly dubious motives ;-)
- parts of libkdepim (general kdepim functionality)
- libsyndication (feed handling library)
- libkmime (email messages handling)
- libkholidays (library for providing holiday information)
I hope that a new module "kdepimlibs" will give us a cleaner modularization of our code and make development easier and more efficient, especially in the current KDE 4 times where due to the developing nature of the framework it's often required to compile whole modules or at least well-defined parts of it.
What do you think?
|
|
Kevin Krammer replied with his thoughts, and an extended viewpoint on the idea:
|
I not only think that this is a good idea, I'd like to point out that this is a general problem with our module libs.
Another example where the impossibility or difficulty of intramodule dependencies are negatively affecting development is kde-edu.
By its nature this module has a wide range of application types, from educational games to tools for teachers. It has come up more than once that it would be of great help to be able to use kdegames libraries or be able to embed a KOffice part.
The KDE module structure encourages packagers to include the libraries in the same package as the binaries, which makes any of the above use cases a no-go for kde-edu (since depending on the whole kdegames with all its game data is out of question).
So it would be great if this could be solved on a wider scale, making it possible to have applications use more than just the core libraries. As it is now applications that are part of the KDE main modules have less possibilities than external applications or have to result to code duplication.
|
|
A more detailed per-library reasoning behind the proposal can be read at http://lists.kde.org/?l=kde-core-devel&m=114543672203558&w=2.
|
|
| Statistics |
|
| Contents |
|
|
Bug Fixes |
Features |
Optimise |
Security |
Other |
|
Accessibility |
 |
|
|
|
|
|
Development Tools |
![[*]](/images/standard/bugfixes) |
![[*]](/images/standard/features) |
|
|
![[*]](/images/standard/other) |
|
Educational |
|
|
|
|
|
|
Graphics |
|
|
|
|
|
|
KDE-Base |
|
|
![[*]](/images/standard/optimise) |
|
|
|
KDE-PIM |
|
|
|
|
|
|
Office |
|
|
|
|
|
|
Konqueror |
|
|
|
|
|
|
Multimedia |
|
|
|
|
|
|
Networking Tools |
|
|
|
|
|
|
User Interface |
|
|
|
|
|
|
Utilities |
|
|
|
|
|
|
Games |
|
|
|
|
|
|
Other |
|
|
|
|
|
|
|
Bug Fixes |
|
|
|
|
|
|
|
|
|
|
|
Eva Brucherseifer committed changes in /trunk/kdenox/konq-embed/dropin/kio:
|
Download Dialog:
- fixed download cancel
- fixed delay closing of dialog after finished download
remaining bug:
- after cancel dialog doesn't close automatically. Instead you have to
cancel/close a second time |
|
|
|
|
|
|
|
