23rd January 2004 by Derek Kite

This Week...

KStars adds more telescope devices. KAddressbook adds custom field support. Krita gets working brush and new patterns. CSS code from Safari added to Khtml.
Tobias Koenig made a commit to KAddressbook that really caught my eye. This is very cool. And an illustration of the latent power of the KDE platform.
Now you can create your preferred contact data input widget with Qt Designer and save the .ui file under $KDEDIR/share/apps/kaddressbook/contacteditorpages/ The caption of the widget will be used as tab label. As input widgets QLineEdit, KLineEdit, QSpinBox, QCheckBox, QDateTimeEdit, KDateTimeWidget and KDatePicker are supported. To mark this widgets as input fields which shall be saved, just give them a unique name which starts with 'X_'. The names have to be plain ASCII! I'll commit some documentation about this feature later this year ;)
A KDE_3_2_BRANCH was created this week, which will become the 3.2 release. That means HEAD is once again available for development. Some of the development branches were merged back into head, notibly the osnabrueck_branch in KDEPIM. There arose a discussion about the more_examples_branch in kdebindings. Should developers branch off from HEAD? There is obviously differences in opinion. Here are snippets of the thread that followed:
Dirk Mueller wrote:
It seems to me we have to restrict branch creation even more in KDE CVS.
Alexander Kellett responded with feeling:
thats a shame as it just means i'll start using my own repos and not bother making my code part of the kde project.
Dirk explained further:
compared to the case where everyone creates his own branch and only works there this would indeed be much preferable IMHO.

Because CVS is imho a way for many people to work together. if everybody works on his own branch then it is better to not use CVS at all.
Cornelius Schumacher jumped in with his take on the situation:
I think the situation with the branches shows that the freeze for 3.2 was too long. If we would have created the 3.2 branch with beta 1 or something like that many of these branches wouldn't have been created and people would have been able to work together in the HEAD branch. Maybe this is something we should consider for the next release.
Scott Wheeler responded:
Uhm, but things got really bad with (3.1? or was it 3.0?) when we branched too early and it caused a lot of problems because by the time that we released things nobody had been running that branch for a month.

I'd personally just like to see a fast 3.3 release -- like 6 months or something with a 6 week or so freeze...
Stephan Kulow, the release coordinator for 3.2 added:
Yeah, and tons of bugs wouldn't have been fixed and regressions wouldn't have been noticed - because everyone was busy working on cool features.
Alex Kellett explained:
while this may be the case normally in my case it most certainly wasn't the only way to fix bindings is to write examples. based on everyones input (richards, dirks, davids) i think that next time i'll just carry on developing in HEAD even after the hard freeze.

personally i really agree with coolo's hard freeze length and the policies he's kept to. but the fact that i'm then asked why i created a branch (which is just plain obvious...) and implicity told that i wouldn't in the future be able to do so, well, thats just a.. joke.
Stephan Kulow
To be honest: I didn't understand it either. I for one would rather waste some space on the cvs server than risking that a developer looses his work and time because his laptop falls down to the floor (which of course is still a lost of data, but at least it doesn't harm the KDE project :)
Rob Kaper hit the crux of the matter.
You can't plan the time of other developers. Plenty of developers work on areas that barely have any bugs or only bugs that require i18n changes or redesigns to be fixed, so they simply cannot contribute to 3.2 anymore unless you force them to work on specific parts.

The "we must fix bugs first" argument was invalid when we introduced a new style and people complained; and it is invalid still.
Trying to control KDE developers is somewhat akin to herding cats. And that is a feature. Each one comes with their own gifts and interests. Everyone can work on what they want, but there are lessons learned along the way that need to be remembered. Hence the tension at times.
Boudewijn Rempt has been working on Krita. Here are some of his goals:
Sure -- it's still not very exciting, reaching feature parity with KPaint is my first goal :-). I've already added support for Wacom tablets, a (buggy) CMYK colour model, support for PPC and loading of Gimp patterns. The part I'm working on at the moment is the brush tool. It's already possible again to paint with Krita -- but it's not very comfortable. I've tried three approaches, but they all have their own disadvantages
(http://www.valdyas.org/fading/index.cgi/hacking/learning_cpp.html?seemore=y).

...

Patrick Julien did the redesign of the core of Krita begin last year, and I think that it's pretty solid and stable by now. We want to make the set of tools more modular -- make KParts out of them -- but that can wait for a while. One interesting thing about Krita is that it can support any number of colour models or bit depths, and I'm also working on a colour model that supports using colour as if were real paint -- but that will take some time get done.

Anyway, there's life in Krita again.
Ariya Hidayat gave us an update on KSpread
In KSpread, by introducing a wrapper for the current KSpreadUndoAction, I can start migrating many "commands" to the real KCommand. In forthcoming weeks, I plan to switch all the undo actions into the real KCommands, but in the mean time the current solution should work well.

For CVS users, if you find any problem with respect to undo/redo after my changes (which you didn't experience with offical KOffice 1.3), please let me know so I can put more priority on the offending undo actions.

The obvious impact of this change: multiple steps undo and redo, to put KSpread on par with KWord and KPresenter :-P
A year ago, VFolder support was added, many Safari fixes were imported.

Statistics

Commits 2096 by 195 developers, 195279 lines modified, 1647 new files
Open Bugs 5236
Open Wishes 5434
Bugs Opened 475 in the last 7 days
Bugs Closed 467 in the last 7 days

Commit Summary

Module Commits
kde-i18n
356
 
kdenonbeta
241
 
kdelibs
225
 
kdepim
222
 
koffice
184
 
kdeextragear-2
109
 
www
96
 
kdeextragear-1
88
 
kdebase
86
 
kdenetwork
62
 
Lines Developer Commits
2974
 
David Faure
112
 
4328
 
Stephan Kulow
95
 
1277
 
Dirk Mueller
76
 
225
 
Waldo Bastian
68
 
1830
 
Marc Mutz
59
 
1607
 
Ludovic Grossard
57
 
291
 
Stephan Binner
48
 
531
 
Anne-Marie Mahfouf
47
 
39505
 
Ahmad M. Zawawi
41
 
1310
 
Alexander Kellett
39
 

Internationalization (i18n) Status

Language Percentage Complete
British English (en_GB)
100%
 
Spanish (es)
100%
 
Swedish (sv)
100%
 
Danish (da)
100%
 
Serbian (sr)
99.77%
 
Estonian (et)
99.41%
 
Portuguese (pt)
98.65%
 
Brazilian Portuguese (pt_BR)
97.93%
 
Italian (it)
97.46%
 
German (de)
95.18%
 

Bug Killers

No commits found