Re: Replacing Gtk::Action and Gtk::UIManager with Gio::Action and Gtk::Builder
On Thu, 2013-09-26 at 22:45 +0200, Krzysztof Kosiński wrote: 2013/9/26 Murray Cumming murr...@murrayc.com: because we cannot yet break the ABI to add Gtk::Actionable as a base class for several classes: https://git.gnome.org/browse/gtkmm/commit/?id=3381c0aea10891a2dccc49b5e450fd497a3cb807 FWIW: From my perspective, it would be far more desirable to have complete and high quality C++ bindings which break the ABI more often than GTK+, rather than to have incomplete bindings which keep the ABI. I understand, but there are huge practical difficulties when we break the ABI, doing a parallel-installable version of gtkmm. It would take about 2 years for packages to get into the major distros, and another year for applications to start using it. This would create work for us and generally annoy people. We've seen this with the gtkmm-2.0 to gtkmm-2.4 transition and with the GTK+-2.0 to GTK+-3.0 (and gtkmm) transitions. I think it's not worth it until there are more major issues that we would fix. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Replacing Gtk::Action and Gtk::UIManager with Gio::Action and Gtk::Builder
On Tue, 2013-09-03 at 23:04 +0200, Murray Cumming wrote: There are other problems that prevent a simple deprecation of GtkAction: * There is no replacement yet for GtkRadioActionItem: https://bugzilla.gnome.org/show_bug.cgi?id=705656 I meant GtkRecentAction: https://bugzilla.gnome.org/show_bug.cgi?id=707422 This is still the major obstacle to us really deprecating GtkAction and GtkUIManager. I don't see much chance that it will be fixed in the GTK + API soon enough. It doesn't look like this will ever be replaced, and there seems some chance that GNOME applications will just stop having recent files menu items: https://mail.gnome.org/archives/gtk-devel-list/2013-September/msg00022.html * GtkBuilder's menu syntax does not let us define toolbars, like GtkUIManager's syntax did. But apparently I'll be able to get this working with GtkBuilder's old syntax and the items' action-name properties. I've chosen to just do this in code, in the examples. However, we need to use the C API to set the GAction's name on the toolbar button: https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/menus/main_menu/examplewindow.cc because we cannot yet break the ABI to add Gtk::Actionable as a base class for several classes: https://git.gnome.org/browse/gtkmm/commit/?id=3381c0aea10891a2dccc49b5e450fd497a3cb807 So, I think we can leave these classes deprecated after all. I'll post separately about the new API. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Replacing Gtk::Action and Gtk::UIManager with Gio::Action and Gtk::Builder
2013/9/26 Murray Cumming murr...@murrayc.com: because we cannot yet break the ABI to add Gtk::Actionable as a base class for several classes: https://git.gnome.org/browse/gtkmm/commit/?id=3381c0aea10891a2dccc49b5e450fd497a3cb807 FWIW: From my perspective, it would be far more desirable to have complete and high quality C++ bindings which break the ABI more often than GTK+, rather than to have incomplete bindings which keep the ABI. Regards, Krzysztof ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Replacing Gtk::Action and Gtk::UIManager with Gio::Action and Gtk::Builder
On Thu, 2013-08-08 at 10:26 +0200, Murray Cumming wrote: Over the last few days I've spent a long time wrestling with gio's new GAction API, trying to port some gtkmm code that used GtkAction and GtkUIManager, both of which GTK+ has now deprecated. This email is to get some feedback in case I've lost perspective. Note that several GTK+ developers feel that this API has been deprecated too soon, but I am not confident that it will be reversed. We might want to avoid the deprecation in gtkmm even if they do it in GTK+. Here is some code that I've ported in gtkmm-documentation, in the gmenu branch (whose commits must be squashed before putting this in master): http://tinyurl.com/lbgv3uo And here is what the old code looks like in master, using GtkUIManager: http://tinyurl.com/ktmllcb I've tried to make the C++ API as nice as possible, avoiding the need for magic incantations, or the need to understand the overly-conceptual documentation, and avoiding the need to deal with GVariant (Glib::VariantBase and Glib::Variant) too much. For instance, using templated get_*() and set_*() methods as we do with Glib::Value elsewhere. However, we are limited because we have already declared some of the API stable: http://tinyurl.com/kmbyt8d Therefore, our application code still sometimes has to create and cast Variants that it gets from, or needs to give to, some methods. Which is annoying. The convenience API, for toggle items and radio items, that I've created is not pretty. I guess that derived classes would be nicer. I've suggested that the C API should have these: https://bugzilla.gnome.org/show_bug.cgi?id=705655 There are other problems that prevent a simple deprecation of GtkAction: * There is no replacement yet for GtkRadioActionItem: https://bugzilla.gnome.org/show_bug.cgi?id=705656 I meant GtkRecentAction: https://bugzilla.gnome.org/show_bug.cgi?id=707422 This is still the major obstacle to us really deprecating GtkAction and GtkUIManager. I don't see much chance that it will be fixed in the GTK+ API soon enough. * GtkBuilder's menu syntax does not let us define toolbars, like GtkUIManager's syntax did. But apparently I'll be able to get this working with GtkBuilder's old syntax and the items' action-name properties. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Replacing Gtk::Action and Gtk::UIManager with Gio::Action and Gtk::Builder
On Thu, 2013-08-08 at 16:40 +0200, Kjell Ahlstedt wrote:
Templated get_*() methods can be added as overloaded methods, because
the number of parameters will be different. Example:
_WRAP_METHOD(Glib::VariantBase get_action_state(const
Glib::ustring action_name) const,
g_action_group_get_action_state)
template typename T_Value
void get_action_state(const Glib::ustring action_name,
T_Value value) const;
It's also possible to deprecate the old get_action_state() and add a
new get_action_state_variant(), identical except for its name.
Yes, thanks for the suggestion. I've done that.
I'm not sure whether it's possible to overload other methods, e.g.
_WRAP_METHOD(void change_action_state(const Glib::ustring
action_name, const Glib::VariantBase value),
g_action_group_change_action_state)
template typename T_Value
void change_action_state(const Glib::ustring action_name,
const T_Value value);
Overload resolution prefers a non-template method to a template
method, but perhaps that's true only when the parameter types exactly
match those of the non-template method. The last parameter in a
typical call would not be a Glib::VariantBase but a
Glib::VariantT.
I tried. But you are right, the compiler calls the templated
change_state() with the Variant, trying to call
change_state_variant() with a VariantVariantint, for instance. At
least that would be an API change instead of an ABI change,
because existing already-compiled applications would be unaffected, but
it would be a hard one to detect.
So, in Action, I added
templatetypename T_Value
void change_state(const Glib::VariantT_Value value)
to give the compiler something to call.
https://git.gnome.org/browse/glibmm/commit/?id=8acf6182ee6e54040cec1a049704c7563f67475a
Hopefully there's no case where someone would really want to call
change_state() with a Variant.
It seems to work. Does it seem OK to you? If so, I'll do it for similar
API.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
www.openismus.com
diff --git a/gio/src/action.ccg b/gio/src/action.ccg
index 78cad2d..d3dd74a 100644
--- a/gio/src/action.ccg
+++ b/gio/src/action.ccg
@@ -24,11 +24,4 @@
namespace Gio
{
-void Action::change_state(bool value)
-{
- g_return_if_fail(
-g_variant_type_equal(g_action_get_state_type(const_castGAction*(gobj())), G_VARIANT_TYPE_BOOLEAN));
- change_state(Glib::Variantbool::create(value));
-}
-
} // namespace Gio
diff --git a/gio/src/action.hg b/gio/src/action.hg
index 316631d..2b6db6d 100644
--- a/gio/src/action.hg
+++ b/gio/src/action.hg
@@ -92,27 +92,24 @@ public:
_WRAP_METHOD(bool get_enabled() const, g_action_get_enabled)
- //TODO: Do this when we can break ABI, removing change_state(const Glib::VariantBase value) and change_state(bool)
- //template typename T_Value
- //void change_state(const T_Value value);
- //
- //_WRAP_METHOD(void change_state_variant(const Glib::VariantBase value), g_action_change_state)
-
- _WRAP_METHOD(void change_state(const Glib::VariantBase value), g_action_change_state)
-
/** Request for the state of @a action to be changed to @a value,
- * assuming that the state is boolean.
+ * assuming that the action has the expected state type.
*
- * See g_action_get_state_type().
+ * See get_state_type().
*
* This call merely requests a change. The action may refuse to change
* its state or may change its state to something other than @a value.
- * See g_action_get_state_hint().
+ * See get_state_hint().
*
* @newin{2,38}
* @param value The new state.
*/
- void change_state(bool value);
+ template typename T_Value
+ void change_state(const T_Value value);
+
+ _WRAP_METHOD(void change_state_variant(const Glib::VariantBase value), g_action_change_state)
+
+ _WRAP_METHOD(void change_state(const Glib::VariantBase value), g_action_change_state, deprecated Use the templated method instead, passing a normal C++ type.)
//TODO: Docs
template typename T_Value
@@ -120,13 +117,13 @@ public:
_WRAP_METHOD(Glib::VariantBase get_state_variant() const, g_action_get_state)
- //TODO: Do this when we can break ABI, removing activate_variant(const Glib::VariantBase parameter);
- //template typename T_Value
- //void activate(const T_Value parameter);
- //
- //_WRAP_METHOD(void activate_variant(const Glib::VariantBase parameter), g_action_activate)
+ //TODO: Docs
+ template typename T_Value
+ void activate(const T_Value parameter);
+
+ _WRAP_METHOD(void activate_variant(const Glib::VariantBase parameter), g_action_activate)
- _WRAP_METHOD(void activate(const Glib::VariantBase parameter), g_action_activate)
+ _WRAP_METHOD(void activate(const Glib::VariantBase parameter), g_action_activate, deprecated Use the templated method instead, passing a normal C++ type.)
_WRAP_METHOD(static bool name_is_valid(const
Re: Replacing Gtk::Action and Gtk::UIManager with Gio::Action and Gtk::Builder
2013-08-09 12:17, Murray Cumming skrev:
On Thu, 2013-08-08 at 16:40 +0200, Kjell Ahlstedt wrote:
Templated get_*() methods can be added as overloaded methods, because
the number of parameters will be different. Example:
_WRAP_METHOD(Glib::VariantBase get_action_state(const
Glib::ustring action_name) const,
g_action_group_get_action_state)
template typename T_Value
void get_action_state(const Glib::ustring action_name,
T_Value value) const;
It's also possible to deprecate the old get_action_state() and add a
new get_action_state_variant(), identical except for its name.
Yes, thanks for the suggestion. I've done that.
I'm not sure whether it's possible to overload other methods, e.g.
_WRAP_METHOD(void change_action_state(const Glib::ustring
action_name, const Glib::VariantBase value),
g_action_group_change_action_state)
template typename T_Value
void change_action_state(const Glib::ustring action_name,
const T_Value value);
Overload resolution prefers a non-template method to a template
method, but perhaps that's true only when the parameter types exactly
match those of the non-template method. The last parameter in a
typical call would not be a Glib::VariantBase but a
Glib::VariantT.
I tried. But you are right, the compiler calls the templated
change_state() with the Variant, trying to call
change_state_variant() with a VariantVariantint, for instance. At
least that would be an API change instead of an ABI change,
because existing already-compiled applications would be unaffected, but
it would be a hard one to detect.
So, in Action, I added
templatetypename T_Value
void change_state(const Glib::VariantT_Value value)
to give the compiler something to call.
https://git.gnome.org/browse/glibmm/commit/?id=8acf6182ee6e54040cec1a049704c7563f67475a
Hopefully there's no case where someone would really want to call
change_state() with a Variant.
It seems to work. Does it seem OK to you? If so, I'll do it for similar
API.
Yes, it seems to work. I tested with the attached short program. No
complaints about ambiguous calls, and the correct template
change_state() function is called in both calls. I see no problem with
this solution.
#include giomm.h
#include glibmm.h
int main()
{
Gio::init();
Glib::RefPtrGio::SimpleAction action1 =
Gio::SimpleAction::create(action1, Glib::VariantType(i), Glib::Variantgint32::create(0));
Glib::Variantgint32 variant32 = Glib::Variantgint32::create(17);
action1-change_state(variant32);
action1-change_state(17);
return 0;
}
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Replacing Gtk::Action and Gtk::UIManager with Gio::Action and Gtk::Builder
2013-08-08 10:26, Murray Cumming skrev: I've tried to make the C++ API as nice as possible, avoiding the need for magic incantations, or the need to understand the overly-conceptual documentation, and avoiding the need to deal with GVariant (Glib::VariantBase and Glib::Variant) too much. For instance, using templated get_*() and set_*() methods as we do with Glib::Value elsewhere. However, we are limited because we have already declared some of the API stable: http://tinyurl.com/kmbyt8d Therefore, our application code still sometimes has to create and cast Variants that it gets from, or needs to give to, some methods. Which is annoying. Templated get_*() methods can be added as overloaded methods, because the number of parameters will be different. Example: _WRAP_METHOD(Glib::VariantBase get_action_state(const Glib::ustring action_name) const, g_action_group_get_action_state) template typename T_Value void get_action_state(const Glib::ustring action_name, T_Value value) const; It's also possible to deprecate the old get_action_state() and add a new get_action_state_variant(), identical except for its name. I'm not sure whether it's possible to overload other methods, e.g. _WRAP_METHOD(void change_action_state(const Glib::ustring action_name, const Glib::VariantBase value), g_action_group_change_action_state) template typename T_Value void change_action_state(const Glib::ustring action_name, const T_Value value); Overload resolution prefers a non-template method to a template method, but perhaps that's true only when the parameter types exactly match those of the non-template method. The last parameter in a typical call would not be a Glib::VariantBase but a Glib::VariantT. Kjell ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
