GNOME Bugzilla – Bug 774903
glibmm-2.4: Wrap missing methods in Gio::SettingsSchemaKey?
Last modified: 2017-05-04 12:58:59 UTC
settingsschemakey.hg has the following TODOs: > //TODO: _WRAP_METHOD(const GVariantType * g_settings_schema_key_get_value_type (), g_settings_schema_key_get_value_type) > //_WRAP_METHOD(GVariant * g_settings_schema_key_get_default_value (), g_settings_schema_key_get_default_value) > //_WRAP_METHOD(GVariant * g_settings_schema_key_get_range (), g_settings_schema_key_get_range) > //TODO: _WRAP_METHOD(bool range_check(GVariant *value), g_settings_schema_key_range_check) These should be wrapped as (despite the warnings about 'this should probably not be used') it is really convenient to be able to iterate over a schema and build controls for it dynamically, e.g. for a preferences dialog. There are presumably other, less discouraged use cases too, but the former was the one I have at the moment. But for now we can only get the names and descriptions. I started looking at this but got stuck on the first one, as it seems GVariantType has no implicit conversion to its glibmm counterpart - but I'm not up to speed on how the wrapping really works yet, so I don't know whether this is a real problem. I didn't yet continue and try the others, but I guess they should work, as I've seen similar functions being wrapped with the basic macro and working OK.
Created attachment 341103 [details] [review] [PATCH] SettingsSchemaKey: Wrap missing methods This makes perfect sense and builds fine, but I've not tested it yet.
Your patch looks fine. If you've got write permission to the git repository, you can push it. If not, I can do it. It should definitely be pushed to the master branch. Murray, is this also something for the glibmm-2-50 branch? Usually we don't add API to a stable branch after the x.y.0 version has been released, but I've a feeling that this rule is not absolute for glibmm-2-50 and gtkmm-3-22, which are supposed to be the last branches of glibmm-2.4 and gtkmm-3.0, respectively.
Thanks! I've pushed to master. I'd really appreciate if this could hit 2.50 too.
For now, I'd prefer to avoid adding API to the stable branch of either glibmm or gtkmm, and I feel uncomfortable deprecating API in stable GTK+ too. But we should track what glib and gtk+ do. I can't imagine that there will be no new API in GTK+ 3, but I do guess that they will eventually do that in a proper minor release, as before. Maybe we'll end up doing another stable glibmm-2.4 2.52 and changing glibmm-2-52 to glibmm-2-54. But at some point we have to stop adding API to glibmm-2.4. So, feel free to keep this open for now, in case we want to add this to glibmm-2.4 later.
I understand your concerns. But if we were tracking GLib, then these keys should already have already existed long ago, since they are GLIB_AVAILABLE_IN_2_40. :) I think of patches like this as bugfixes rather than new API, and they don't pose any risk to existing users - quite the opposite by making the class far more useful.
Our policy, and GNOME's policy, is not to add API in stable releases. That way you don't have a huge number of possible versions to worry about when you think about what version you need to depend on.
Following on from the discussion about glibmm-2-52 being stable but API-modifying, could this be included in that release? Thanks.
Push to the glibmm-2-52 branch, which I will release a stable version of soon: https://git.gnome.org/browse/glibmm/commit/?h=glibmm-2-52&id=4e9c04cafc37921652e69e6dee741cf0cac31a17 Thanks.