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 ;)

It seems to me we have to restrict branch creation even more in KDE CVS.

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.

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.

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.

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...

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.

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.

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 :)

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.

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.

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