> On Tuesday 04 of February 2003 18:00, Alexander Neundorf wrote:
> > On Tuesday 04 February 2003 11:24, Stefan Heimers wrote:
> > > This is a good point. I would recommend moving deprecated
> methods out of
> > > qt/kdelibs into a separate libraby.
> >
> > That's not possible, these methods are usually member
> methods which belong
> > to their class.
> >
> > But the #ifdef would be a good thing.
>
>  It should be possible, you can simply omit implementation of
> some methods,
> and as long as they're not referenced, it will be fine. Even
> the #ifdef is
> there, it's called KDE_NO_COMPAT (and QT_NO_COMPAT), so you
> can just add
> "-DKDE_NO_COMPAT -DQT_NO_COMPAT" to your compile flags and try.
>
>  On the other hand, I don't think there should be any
> official support for it,
> as that would be likely to break anything but a carefully
> handled install
> from sources, where the person wouldn't care about things
> like no backwards
> compatibility, possibly broken binary compatibility, and so on.

The main advantage here is not to use these methods in future releases.
In that way you can compile it with those flags and see if some of the
deprecated methods are used, that I am pretty sure (not checked yet)
that they are used in the 3.1.
 
>  300KiB of shared memory isn't that much, given the libs take
> roughly 15MiB in
> total. Moreover I think it would be less, most NO_COMPAT
> methods are simple
> wrappers, so they would be less than 1KiB each.

I was not talking about NO_COMPAT methods but methods that are documented
in their documentation header as @deprecated.

> --
> Lubos Lunak
> KDE developer
> ---------------------------------------------------------------------
> SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
> Drahobejlova 27  tel: +420 2 9654 2373
> 190 00 Praha 9   fax: +420 2 9654 2374
> Czech Republic   http://www.suse.cz/
>
> _______________________________________________
> Kde-optimize mailing list
> Kde-optimize@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-optimize
>