After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 441422 - Documentation for Gtk::FileChooser::get_filenames() is misleading
Documentation for Gtk::FileChooser::get_filenames() is misleading
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: documentation
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2007-05-26 14:51 UTC by Jonathon Jongsma
Modified: 2007-05-28 13:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to override gtk+ docs for some FileChooser methods (3.23 KB, patch)
2007-05-26 17:26 UTC, Jonathon Jongsma
none Details | Review
updated patch with changelog patched as well (3.75 KB, patch)
2007-05-26 17:29 UTC, Jonathon Jongsma
none Details | Review

Description Jonathon Jongsma 2007-05-26 14:51:24 UTC
It implies that we have to manually free the list of filenames returned, which (as far as I know) is not the case.  It looks like some GLib documentation slipped through.
Comment 1 Jonathon Jongsma 2007-05-26 17:26:42 UTC
Created attachment 88854 [details] [review]
Patch to override gtk+ docs for some FileChooser methods

There were actually more methods that this affected than just get_filenames().  I changed them all to say that you don't need to free them.  OK to commit?
Comment 2 Jonathon Jongsma 2007-05-26 17:29:04 UTC
Created attachment 88855 [details] [review]
updated patch with changelog patched as well
Comment 3 Murray Cumming 2007-05-28 09:13:57 UTC
Excellent. Thanks. Please commit. Every now and then I try to find and fix these, but new ones keep popping up.
Comment 4 Jonathon Jongsma 2007-05-28 13:45:14 UTC
OK, I've fixed this in trunk and gtkmm-2-10.  Is it worth going back any farther?
Comment 5 Murray Cumming 2007-05-28 13:49:49 UTC
No, that should be fine. Thanks.