GNOME Bugzilla – Bug 330535
GKeyFile not wrapped
Last modified: 2006-09-19 20:37:36 UTC
Wrapping of the GKeyFile object. See: http://www.gtk.org/api/2.6/glib/glib-Key-value-file-parser.html If this is just a matter of writing an hg and a ccg file and making the necessary build modifications i'll happily write a patch for this.
Yes, it's probably just a matter of doing that. That would be great.
Created attachment 59669 [details] [review] Glib::KeyFile wrapper. I've got some example code, I was going to include as well, but I couldn't find a way to add it to the patch easily so I've left it out. I can always post it here.
Looks really good. Could you post that example here, maybe in a tarball?
I would prefer to rename bool delete_c_instance to take_ownership, and glibmm_generated to owns_gobject_, because that's more like what we do sometimes elsewhere. It is awkward, but hopefully almost nobody will need to use it because other API does not return GKeyFile instances. I'd prefer that we _always_ own the C object, and force people to copy the C object if necessary. But unfortunately, I don't see a copy function in the C API. That happens sometimes. And of copying of our own C++ instance isn't possible (because we can't copy the C instance) then we should probably add private (and non implemented) declarations of the copy constructor and operator=(). I'd guess that you don't need the NO_GTYPE with the _WRAP_ENUM(KeyFileFlags, GKeyFileFlags, NO_GTYPE) because glib and GTK+ usually register the types properly. You might want a default flags value for load_from_data_dirs(const std::string& file, std::string& full_path, KeyFileFlags flags); The get_*() and has_*() methods should be const. The existing code does method { } rather than method { } so I would prefer that it stay consistent.
Created attachment 59743 [details] KeyFile example program. Unzip this into glibmm/examples/, add examples/keyfile/Makefile to AC_CONFIG_FILES in configure.in and keyfile to example_dirs in examples/Makefile.am, and compile as normal.. if all goes should create an executable called test in glibmm/examples/keyfile which should run through some of the Glib::KeyFile functionality. And thanks for the tips. I'll try and get those done and submit a new patch tomorrow.
Created attachment 59767 [details] [review] Glib::KeyFile wrapper v2 This should address all your comments. Except, when I remove the NO_GTYPE it refuses to compile because 'Value is not a template', so i've left them in.
You probably don't want to hear this right now, but I just remembered that this has missed the API freeze for GNOME 2.14, so it could only be released in a stable version of glibmm in about 6 months's time. I'll branch glibmm soon after GNOME 2.14, so I can commit this. In theory, we can ask for a freeze-break but I don't think that's a good idea, because we wouldn't have enough time to get feedback on the new API. (GNOME 2.14 will have glibmm (and glib) 2.10 and gtkmm (and GTK+) 2.8.) I'll investigate the "Value is not a template" issue at that time. Many thanks and well done.
Heh, not to worry, atleast it's done and written now, and if I'd known I might not have written it, so it might have turned out better in the long run. :)
Committed to glibmm HEAD. I can't find anything at all wrong with this patch. Well done. The *_as_* method names are not too pretty, but I can't think of anything better - let's see what people think when they see it in a tarball.