Re: Various questions about Gtk::PlacesSidebar
On Tue, 2013-09-03 at 22:14 +0100, Chris Vine wrote: On Tue, 03 Sep 2013 22:34:51 +0200 Murray Cumming murr...@murrayc.com wrote: On Tue, 2013-09-03 at 21:20 +0100, Chris Vine wrote: On Tue, 03 Sep 2013 09:40:19 +0200 Murray Cumming murr...@murrayc.com wrote: On Mon, 2013-09-02 at 16:13 +0200, Krzysztof Kosiński wrote: 2013/9/2 Kjell Ahlstedt kjell.ahlst...@bredband.net: Objects of classes that derive from Gtk::Object are not put in Glib::RefPtrs. I'm not sure why. I'm also a little confused by this but it probably has something to do with Gtk::manage(). GtkWidgets don't use simple reference counting in the GTK+ C API. They can be destroyed at any time regardless of the reference count. So we can't use RefPtr with them easily. That is not really true. widgets are always (and only) destroyed when their sunk reference count reaches 0, Calling gtk_widget_destroy() will destroy a widget. Containers destroy their child widgets by default in GTK+ with C. On reflection I think you may well be right (except that it _is_ the case that widgets will only be finalized when their reference count reaches 0). gtk_widget_destroy() calls g_object_run_dispose() which causes the object to drop all references to other objects. This will cause all containers to drop their references to it. However, if the references dropped includes other objects which are part of the widget's own implementation then there are problems. The documentation for gtk_widget_destroy() sort-of suggests that keeping a reference will keep the widget alive: ... If the widget is inside a container, the widget will be removed from the container. If the widget is a toplevel (derived from GtkWindow), it will be removed from the list of toplevels, and the reference GTK+ holds to it will be removed. Removing a widget from its container or the list of toplevels results in the widget being finalized, unless you've added additional references to the widget with g_object_ref(). It would be somewhat pointless to not finalize the widget if in fact it is unusable. At a suitable opportunity I will do a test and see which result occurs. However, GTK+ containers don't call gtk_widget_destroy(): users do. GTK+ containers just drop their references when being finalized. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list Thank you all. Do you have something on how to wrap a gpointer argument? Regards, Juan. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Various questions about Gtk::PlacesSidebar
On Mon, 2013-09-02 at 16:13 +0200, Krzysztof Kosiński wrote: 2013/9/2 Kjell Ahlstedt kjell.ahlst...@bredband.net: Objects of classes that derive from Gtk::Object are not put in Glib::RefPtrs. I'm not sure why. I'm also a little confused by this but it probably has something to do with Gtk::manage(). GtkWidgets don't use simple reference counting in the GTK+ C API. They can be destroyed at any time regardless of the reference count. So we can't use RefPtr with them easily. -- 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: Various questions about Gtk::PlacesSidebar
On Tue, 03 Sep 2013 09:40:19 +0200 Murray Cumming murr...@murrayc.com wrote: On Mon, 2013-09-02 at 16:13 +0200, Krzysztof Kosiński wrote: 2013/9/2 Kjell Ahlstedt kjell.ahlst...@bredband.net: Objects of classes that derive from Gtk::Object are not put in Glib::RefPtrs. I'm not sure why. I'm also a little confused by this but it probably has something to do with Gtk::manage(). GtkWidgets don't use simple reference counting in the GTK+ C API. They can be destroyed at any time regardless of the reference count. So we can't use RefPtr with them easily. That is not really true. widgets are always (and only) destroyed when their sunk reference count reaches 0, and incrementing the reference count before removing a widget from a container is how you move them between containers. There is no problem with holding a non-top level widget by RefPtr provided you call g_object_ref() on the C object first, which is inconvenient with gtkmm and leaves the opportunity to forget to do so. So it is inadvisable. With top level windows it would be highly confusing to take your own reference in this way. You expect a top level window to disappear when you call gtk_widget_destroy() on it to drop GTK+'s top level reference, not hang around. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Various questions about Gtk::PlacesSidebar
On Tue, 2013-09-03 at 21:20 +0100, Chris Vine wrote: On Tue, 03 Sep 2013 09:40:19 +0200 Murray Cumming murr...@murrayc.com wrote: On Mon, 2013-09-02 at 16:13 +0200, Krzysztof Kosiński wrote: 2013/9/2 Kjell Ahlstedt kjell.ahlst...@bredband.net: Objects of classes that derive from Gtk::Object are not put in Glib::RefPtrs. I'm not sure why. I'm also a little confused by this but it probably has something to do with Gtk::manage(). GtkWidgets don't use simple reference counting in the GTK+ C API. They can be destroyed at any time regardless of the reference count. So we can't use RefPtr with them easily. That is not really true. widgets are always (and only) destroyed when their sunk reference count reaches 0, Calling gtk_widget_destroy() will destroy a widget. Containers destroy their child widgets by default in GTK+ with C. and incrementing the reference count before removing a widget from a container is how you move them between containers. Yes, that is necessary, though we do that for you in gtkmm. There is no problem with holding a non-top level widget by RefPtr provided you call g_object_ref() on the C object first, which is inconvenient with gtkmm and leaves the opportunity to forget to do so. So it is inadvisable. I believe that this would lead to having RefPtrs pointing to invalid (destroyed) GtkWidget instances. I suppose you could improve this by letting the RefPtr know when the widget is going to be destroyed, allowing us to check the RefPtr at runtime, but I don't think you could stop the GtkWidget destruction, I don't think GTK+ would want you to, and I don't think it would be a nice C++ API. With top level windows it would be highly confusing to take your own reference in this way. You expect a top level window to disappear when you call gtk_widget_destroy() on it to drop GTK+'s top level reference, not hang around. -- 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: Various questions about Gtk::PlacesSidebar
On Tue, 03 Sep 2013 22:34:51 +0200 Murray Cumming murr...@murrayc.com wrote: On Tue, 2013-09-03 at 21:20 +0100, Chris Vine wrote: On Tue, 03 Sep 2013 09:40:19 +0200 Murray Cumming murr...@murrayc.com wrote: On Mon, 2013-09-02 at 16:13 +0200, Krzysztof Kosiński wrote: 2013/9/2 Kjell Ahlstedt kjell.ahlst...@bredband.net: Objects of classes that derive from Gtk::Object are not put in Glib::RefPtrs. I'm not sure why. I'm also a little confused by this but it probably has something to do with Gtk::manage(). GtkWidgets don't use simple reference counting in the GTK+ C API. They can be destroyed at any time regardless of the reference count. So we can't use RefPtr with them easily. That is not really true. widgets are always (and only) destroyed when their sunk reference count reaches 0, Calling gtk_widget_destroy() will destroy a widget. Containers destroy their child widgets by default in GTK+ with C. On reflection I think you may well be right (except that it _is_ the case that widgets will only be finalized when their reference count reaches 0). gtk_widget_destroy() calls g_object_run_dispose() which causes the object to drop all references to other objects. This will cause all containers to drop their references to it. However, if the references dropped includes other objects which are part of the widget's own implementation then there are problems. The documentation for gtk_widget_destroy() sort-of suggests that keeping a reference will keep the widget alive: ... If the widget is inside a container, the widget will be removed from the container. If the widget is a toplevel (derived from GtkWindow), it will be removed from the list of toplevels, and the reference GTK+ holds to it will be removed. Removing a widget from its container or the list of toplevels results in the widget being finalized, unless you've added additional references to the widget with g_object_ref(). It would be somewhat pointless to not finalize the widget if in fact it is unusable. At a suitable opportunity I will do a test and see which result occurs. However, GTK+ containers don't call gtk_widget_destroy(): users do. GTK+ containers just drop their references when being finalized. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Various questions about Gtk::PlacesSidebar
2013-09-01 11:51, Juan Rafael García Blanco skrev: Hi, I'm trying to wrap the new GtkPlacesSidebar api. I've run into a few problems, so I've read a little bit how my problem has been resolved for other classes. Still I'm not sure what to do about the following (maybe it would have been better to split this email into more pieces, sorry): - I thought that whenever a C pointer is used in the C api, a RefPtr should be put in place in gtkmm. Is that true? Does it apply almost everywhere? I've found widgets that do not follow this rule and they use C++ plain pointers instead. Objects of classes that derive from Gtk::Object are not put in Glib::RefPtrs. I'm not sure why. - The GtkPlacesSidebar struct is defined in the .c file. This forces me to add the no_default_handler keyword at the end of the _WRAP_SIGNAL macro. I've checked that not all Gtk classes are defined in the .c, and most are defined in the .h. Should we notify this issue to the C folks? I don't think it's a problem that GtkPlacesSidebar is defined in the .c file. It *is* a problem that GtkPlacesSidebarClass is defined in the .c file. GtkAccelMapClass is also defined in the .c file, but it does not contain signals or virtual functions, and then it's no problem. GtkPlacesSidebarClass is probably worth a bug report or a question on one of the gtk mailing lists. You might also ask them to put more specific data types in the registration of the signals. It would make life easier for you. E.g. in the registration of open_location the parameter /location/ has type G_TYPE_OBJECT, but in GtkPlacesSidebarClass::open_location() its type is GFile*. I don't understand why it's not G_TYPE_FILE in the call to g_signal_new(). - What can be done when a signal handler declares one of its arguments as a gpointer? I've found little information on this. The signal handler I'm thinking of is in GtkPlacesSidebar and that argument is actually a GSList. - How can I create a const version of this: #m4 _CONVERSION(`GSList*',`std::vector Glib::RefPtrGio::File ',`Glib::SListHandler Glib::RefPtrGio::File ::slist_to_vector($3, Glib::OWNERSHIP_DEEP)') _WRAP_METHOD(std::vector Glib::RefPtrGio::File list_shortcuts(), gtk_places_sidebar_list_shortcuts) Thank you very much in advance. I hope not many of my questions are solved in the docs; I've checked them, I promise. Regards, Juan. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Various questions about Gtk::PlacesSidebar
2013/9/2 Kjell Ahlstedt kjell.ahlst...@bredband.net: Objects of classes that derive from Gtk::Object are not put in Glib::RefPtrs. I'm not sure why. I'm also a little confused by this but it probably has something to do with Gtk::manage(). Regards, Krzysztof ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Various questions about Gtk::PlacesSidebar
Thank you very very much. That was the expertise I was looking for :) On Sep 2, 2013 4:13 PM, Krzysztof Kosiński tweenk...@gmail.com wrote: 2013/9/2 Kjell Ahlstedt kjell.ahlst...@bredband.net: Objects of classes that derive from Gtk::Object are not put in Glib::RefPtrs. I'm not sure why. I'm also a little confused by this but it probably has something to do with Gtk::manage(). Regards, Krzysztof ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Various questions about Gtk::PlacesSidebar
Hi, I'm trying to wrap the new GtkPlacesSidebar api. I've run into a few problems, so I've read a little bit how my problem has been resolved for other classes. Still I'm not sure what to do about the following (maybe it would have been better to split this email into more pieces, sorry): - I thought that whenever a C pointer is used in the C api, a RefPtr should be put in place in gtkmm. Is that true? Does it apply almost everywhere? I've found widgets that do not follow this rule and they use C++ plain pointers instead. - The GtkPlacesSidebar struct is defined in the .c file. This forces me to add the no_default_handler keyword at the end of the _WRAP_SIGNAL macro. I've checked that not all Gtk classes are defined in the .c, and most are defined in the .h. Should we notify this issue to the C folks? - What can be done when a signal handler declares one of its arguments as a gpointer? I've found little information on this. The signal handler I'm thinking of is in GtkPlacesSidebar and that argument is actually a GSList. - How can I create a const version of this: #m4 _CONVERSION(`GSList*',`std::vector Glib::RefPtrGio::File ',`Glib::SListHandler Glib::RefPtrGio::File ::slist_to_vector($3, Glib::OWNERSHIP_DEEP)') _WRAP_METHOD(std::vector Glib::RefPtrGio::File list_shortcuts(), gtk_places_sidebar_list_shortcuts) Thank you very much in advance. I hope not many of my questions are solved in the docs; I've checked them, I promise. Regards, Juan. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
