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 <olav@xxxxxxxxxx> wrote:
On Wed, Jan 04, 2012 at 02:54:59PM -0300, salsaman wrote:You've send various emails and started demanding support. If you need
> Why are you all having problems answering a very simple question ?
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
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
