Kexi supports CSV import. kttsd adds support for Cepstral voices. Kopete add webcam receiving support for yahoo. Kopete implements global identity for all the IM services. KTorrent add search capability. Kopete support for Skype is in progress. Datakiosk adds prompts for sql queries and search.
The work on KDE4 continues. Many of the base applications can be run, although not reliably. The strategy is to get everything building and running, then start to sort out the remaining problems. While this is happening, bugfixes and improvements continue to be made to the KDE3 codebase in preparation for KDE 3.5. These fixes need to be ported to the KDE4 development tree. The porting from trunk will become more and more difficult as the two trees diverge. Applications trying to port face libraries that are a moving target. Obviously the situation is somewhat confusing and could become unmanageable. Stephan Kulow started a thread on kde-core-devel to elicit comments on how to best approach this. [1]
As originally announced I would like to have trunk based on Qt4 really soon now. For this I would like to branch off trunk this friday (and use the time till then to do an initial port of some more modules).
The translations were unaffected and would happen from the 3.5 branch. The 3.5 branch would still be an active development branch, but every change done there has to be done also in trunk. The actual schedule on merging might vary from app to app or even module to module, but that should be the goal. We can even make a public list of all revisions happened to 3.5 branch and strike off forward ports through a commit keyword (or some similiar mechanism).
But I think this needs to be done even before Qt4 is released. And it's no longer a completly uncertain adventure, but we know pretty well by now how much porting effort is behind Qt4 - but what we do not know is how well it runs. Getting konqueror to compile was done in pretty short time, but getting it to work for daily usage will still take a good while and we should as project should have good overview over it.
Everyone is free to stay and develop for KDE 3.5 as long as he feels like it, but everyone should be aware that the development for it needs to be ported to KDE4 without too much major pain or you're just asking for frustration.
Some of the issues were elaborated upon as the discussion continued. Stephan's goals is that [2]
KDE4 is the main target, KDE 3.5 development is defined as backport
OK, so how about dropping the idea of KDE 3.5 then? At the Akademy discussion KDE 3.5 was always discussed as "rest release". We really can't afford having KDE 4 be released in two years from now. And to get that done, we need all manpower we can get.
Take it as it is, but KDE 3.5 _is_ a step child and we can continue this "we need a KDE 3.X (where X is larger than the previous released)" discussion for years now. It just won't help us. We started with KDE 4 development - given fact. This means KDE 3.5 sees less development than any other KDE3 release - given fact. Now we have to make sure to find the balance between a) getting KDE 3.5 out at all and b) getting KDE 4 out in an overseeable future.
These sometimes radical proposals brought forth many opinions. (Stephan Kulow acknowledged that he was being somewhat outrageous on purpose [4]. When herding cats an easy way to get everyone's attention is to get everyone mad at you.) The KDEPIM developers came to a consensus during their recent meeting on a future roadmap. [5] Cornelius Schumacher wrote in part:
The basic assumption of the roadmap is that we won't be able to do feature work in two different branches, while porting one branch to Qt 4, because we don't have the resources to cope with the inevitable merging hell which would result from this. So we propose to concentrate on the 3.5 release and start Qt 4 porting and KDE 4 feature work when 3.5 is basically done.
That means that the KDEPIM porting effort will begin in August after the release of KDE 3.5. Many KDEPIM developers, including Thomas Zander [6] , Martijn Klingens [7] and Ingo Kloecker [8] asked that trunk/KDE/kdepim be read-only to prevent a confusing mess. Their reasoning is that with the current manpower it is reasonable to concentrate development efforts on one tree. Once the 3.5 features are complete, then KDE 4 development will begin in earnest.
Other developers stated their planned schedules. Aaron J. Seigo wrote [9]:
i noticed people have touched kde4/kdebase/kicker which i really wish they hadn't. if you had to run a KDE3 linked kicker for another month or two i doubt it would've been a cause of great consternation, but making changes in kicker right now really doesn't mesh with the schedule i've set out, much as with the kdepim people
and with some suggestions on how to go about this: [10]
i think there is a compromise to be had in realizing that applications will start porting at different stages according to their priorities and schedules. so there will be some coordination needed here between "core" and "KDE applications". i think this also really helps to self-define the lines between "KDE core" and "KDE applications"
in any case, i'd recommend that "small apps" such as kdeutils, kdetoys, kdeadmin, etc. be brought over immediately, bar none. ditto with kdelibs/kdebase (yes, in spite of me dragging my heels for up to another 4 weeks with kicker ;) ...
kdemm probably will want to come over sooner than later too due to the massive changes they will need, but that's something best expressed by the kdemm developers.
as for the rest, i'd make it clear to them the issues and let them schedule their devel switch as it works for them. we should respect those wishes and not port the code on them in the meantime. many of these projects rarely or never touch kdelibs/base anyways and so for them following a moving target until it settles down a wee bit may not be worth it.
For now I merge over changes done in trunk and it's still pretty easy to merge as we haven't done too many changes that can't be easily reverted and redone (calling qt3to4 and get it to compile). And as I said: if your feature freeze is end of june, that's fine. You just switch working to 3.5 branch and leave trunk alone for the month. If you're done, you port it over in one go - either reusing or overwriting the changes done in trunk so far.
I'm also fine with whole of kdepim joining trunk development only in august. I even suggest we remove kdepim from trunk then and copy it back into trunk later. But that doesn't work for kicker. We really need a gradually ported KDE4 to test changes done to the framework. And we have to make sure we're not loosing overview - and if all KDE 3.5 development is going to be merged by me, we're going to loose overview. So I want a change in policy who is responsible for merging KDE 3.5 development into the then main development branch - I don't want to dictate a policy on when this needs to be done and not even how.
This subject was brought up to try to avoid a situation where there are two separate development efforts that over time become more and more difficult to merge. We shall see how it works in the coming months.
mouseMoveEvent(): Prevent the moving vertex from disappearing underneath a widget, else there's no way to get it back. The current behavior is somewhat jerky - improvements are very welcome :) BUG:106356
* At the moment require 'Qt' and require 'Korundum' statements can't appear in the same ruby program. Suitable fatal error messages are now displayed to indicate the cause of the problem. Fixes bug reported by Caleb Tennis and Dave M CCBUGS: 100123
Fixes bug 105995. I have placed several controls to check that the number of fields matches the selection in the window, and that the fields are valid. If errors are found a warning per line is issued explaining the cause. The program skips the line with problems and continues with the next one. The warning is only seen if KStars is run from the command line. If any error has been found a KMessage box is shown to tell the user that some lines have not been processed.
I have to port this correction to the KDE 3.4 branch but that will break the message freeze.
I also need to do the same checking with the rest of modules.
Try to check if the given file is not a directory, exists and is readable (However it helps not much, except in the case of the mini-cli trying a thumbnail on a directory. Otherwise khtmlimage eats the KIO error (to kdDebug) and shows the NULL image.) CCBUG:90629
Patch by Trolltech to workaround miscompilation of Qt 3 with gcc 4.0.x.
"It results in functions such as QString::number to not work correctly, which in turn results in bugs like generated postscript during printing containing garbage."
The error message used was not relevent for most device types except for CD/DVD drives. We now use the old message for CD/DVD only, and introduce a new one to take care of the other devices.
Improve the groff basic support: - fix a few of the special characters (by looking into Unicode list) - change the way of setting fonts, always as HTML (The new implementation has the drawback not to have any font number anymore. So may be we need to go back a little in future, assuming needing \n[.f] ) (We do not use/abuse the KDE CSS classes as fonts anymore.) - as we do not know .ftr (font translation) offer a few other fonts too (The main ones of the ps output of groff) (Sorry, still no Japanese fonts, as I have no idea how to test. But Qt might be smarter anyway.) - fix the off-by-one easy-to-do error in scan_escape_direct and friends - fix single letter string variables and number registers. - new code for the font setting escape \f (including long names now) - fix \\ for getting a backspace - use HTML for the corresponding requests .SM and .SB - a few other minor details
CCBUG:106067 (It looks rather good this time, except the .while condition problem, which still polutes the text with >=2 here and there.)
A few simplifications: - use "const" on a few QStrings - get the path for the kio_man.css file only one time at start - construct the to kio_man.css on the fly when writing to the string - limit the i18n() to the real text (especially if the tags are unbalanced) - do not use QFile::encodeName when it has to be given as QString to the stream - make "static" the function sectionName - use const_iterator (as it seems more portable to Qt4) - use ++it instead of it++ for iterators (Partly follow-up of bug #99384) CCBUG:99384
![[*]](/images/standard/features.png)
![[*]](/images/standard/bugfixes.png)
![[*]](/images/standard/other.png)
![[*]](/images/standard/optimise.png)