(well, my previous comment on documentation aside....) i have been caught by this in the past as well: that documentation related to deprecated functions is woefully lacking. it is emminently unhelpful to simply state "stop using this call".
in all cases, there is a story behind why something has become deprecated, except that in most cases, this story goes undocumented, leaving a coder who must convert code (always a joy) pretty much on their own in determining: - exactly why it's been deprecated; but even more crucially, - exactly how to proceed in providing a replacement. (and given that we're talking about from one library to another in this case, even moreso) IMHO: documentation describing a call as deprecated should, at the very least, include a pointer to what replaces it. and, where possible, the back-story/reasoning behind the deprecation in the first place. and when so documented, no need for pissy postings from any side since no posting would ever get generated in the first place. richard On Thu, Jan 5, 2012 at 6:09 PM, Olav Vitters <[email protected]> wrote: > On Wed, Jan 04, 2012 at 02:54:59PM -0300, salsaman wrote: > > Why are you all having problems answering a very simple question ? > > You've send various emails and started demanding support. If you need > support that badly, then it is quite normal to go to a company which can > provide such services for you. > > If you're fine with the normal support, do understand that you're asking > it in a period where most developers are simply on vacation. Sending > multiple messages in various days is also a bit counterproductive. E.g., > I look at threads without a reply. I often don't look who replied on it. > > -- > Regards, > Olav > _______________________________________________ > gtk-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gtk-list >
_______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
