Re: Accompany index of deprecated symbols with GTK+ version?

On Monday 13 November 2006 22:36, David NeÄas (Yeti) wrote:
Mass removal of deprecated symbols *only* for the purpose of
removal of deprecated symbols is a good method to waste time
and bring new bugs.

my understanding of "deprecated" is that those methods are not
maintained anymore. Or at least not maintained as good as
the main API is maintained.

Also my understanding is that whenever GTK+ 3 should happen,
all deprecated symbols will not be there anymore.

I might be wrong with these assumptions!
Any URL where I can learn more about the GTK+ deprecation philosophy?

However, I learned that for quite a number of methods it is
a good idea to drop the deprecated ones and instead
use the replacements (less buggy, better UI, better source code
readability, less source code, better performance).
Usually it should indeed make sense, because otherwise there
would have been no need to implement a replacement ;-)

Now, if you think such an index would be so useful you can
write a gtk-doc patch to enable some kind of version info in
the conditional compilation constructs (the easy part) and
actually add the proper deprecation version info to the
headers (the hard part).  Or invent some other method to get
the information there, like semiautomatic extraction using
tarballs of previous Gtk+ versions...  But in my opinion it
does not worth the work.

Seems noone else is interested in these things I need/care.
So indeed it does not make sense to implement a general solution.



Jan-Oliver Wagner:  | GISpatcher:
Kolab Konsortium : | Thuban    :
Intevation GmbH  :       | Kolab     :
FreeGIS          :         | GAV       :

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]