Moving 3.5 development into branches/KDE/3.5

[Maksim Orlovich]

>
> I believe that is the best solution so far. Adding my own thoughts:
>
> - now: a relaxed feature and message freeze for is announced
> trunk/KDE/kdelibs
> - now + 2 weeks: trunk/KDE/kdelibs branches off to branches/KDE/3.5 and
> KDE4 takes over
> - kdelibs 3.5 gets bugfixes and maybe even some features --- if backported
> from KDE4

I am not sure I view this as a better strategy, but IMHO, whatever
happens, the following constraints should be encouraged to be kept to by
3.5 development:
1) No new use of the old-style socket classes.
2) No new use of QPtrList, and in general, of setAutoDelete
3) No new use of raster ops.
4) No new code painting on widgets outside paint events

Anyone think of anything else that's a pain to port?