current state of KDE_DEPRECATED ?
Christian Ehrlicher
Ch.Ehrlicher at gmx.de
Thu Mar 16 21:56:49 GMT 2006
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).
Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060316/6e5926dc/attachment.sig>
More information about the kde-core-devel
mailing list