current state of KDE_DEPRECATED ?

[Nicolas Goutte]

On Thursday 16 March 2006 22:56, Christian Ehrlicher wrote:
> David Faure schrieb:
> > On Thursday 16 March 2006 10:27, Thiago Macieira wrote:
> >> Looks to me like common sense: why keep deprecated methods in KDE 4?
> >> The only reason why they'd still be there is compatibility:
> >
> > Yes, the reason is compatibility, and that's a good enough reason for
> > now, IMHO. There's enough work porting away from qt3; porting away from
> > kde3 just adds to it, so why put even more work on our plate? We can
> > leave it for later (when rewriting code we then take the opportunity to
> > fix some deprecation warnings) instead of breaking compilation in all kde
> > modules for no urgent reason and driving more people away from trunk
> > because it doesn't compile...
> >
> >>> And what about moving deprecated classes to kde3support? I don't know
> >>> if I ca do this without breaking a lot of kde programs...
> >>
> >> KDE3Support is really a big question mark unanswered. Who's going to
> >> write it?
> >
> > kde3support doesn't need to be "written" from scratch, it's mostly
> > classes from kde3 ported to KDE4.
>
> But nobody answered my question - can we move deprecated classes to
> kde3support without making big trouble like I did with KDE_DEPRECATED?
> Maybe renaming them to K3... ?

> This would reduce the deprecated warnings a little bit because I see no
> need to make K3-classes compile without qt3support (and kde3support can
> be compiled without QT3_SUPPORT_WARNINGS).

If it is the case, then we must put kde3support out of kdelibs or change 
the rule that kdelibs should not need qt3support.


>
> Christian

Have a nice day!