Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
On 08.02.2013 04:08, Simon Feltman wrote: I've created a ticket and proposed patch for GTK+: https://bugzilla.gnome.org/show_bug.cgi?id=693393 I am looking for feedback to see if this type of thing is even acceptable and if it's worthy of further pursuit. Won't gobject-introspection silently turn the (transfer full) annotation into (transfer none) due to the special handling for GInitiallyUnonwed descendants? Also, the list in the bug is missing Gtk.CellRenderer.start_editing (the vfunc, not the method). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
On 07.02.2013 01:12, Simon Feltman wrote: Unfortunately there are a few more of these: Gtk.Action.create_menu Gtk.Action.create_menu_item Gtk.Action.create_tool_item Gtk.PrintOperation.create_custom_widget Gtk.PrintOperation.create-custom-widget (signal) Gladeui.EditorProperty.create_input Gladeui.BaseEditor.build_child? Gladeui.BaseEditor.build-child (signal) Also: Gtk.CellRenderer.start_editing. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
On 04.02.2013 03:39, Simon Feltman wrote: I am starting to warm up to an idea where we simply never sink objects and always follow the rules entailed by ownership transference annotations already in place, with one caveat: g_object_new is annotated as transfer full but can also return floating references. In this case, we must check the returned type and not believe the annotation when it returns InitiallyUnowned instances, but instead treat it like transfer none and add a new ref. What about custom implementations of classes that are supposed to take over floating refs? For example, how would you write a custom GtkContainer subclass in Python with your scheme? Wouldn't you then need a way to explicitly sink the floating ref? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
I cannot offer a solution, just a grumpy observation: The problem occurring with this kind of ref sequence is due to gobject-introspection's decision to always set transfer-ownership=none for GInitiallyUnowned descendants and the resulting habit of language bindings to always sink floating refs. For previous discussion: https://bugzilla.gnome.org/show_bug.cgi?id=657202. On 17.01.2013 01:42, Simon Feltman wrote: The pygobject specific problems I mention could be solved by tracking incoming floating refs and re-floating them upon closure exit if the python ref is not stored anywhere (or by attempting to just keep it floating). The approach in parentheses is used by the Perl bindings: • For constructors which return GInitiallyUnowned instances, we internally force transfer-ownership=full. • We generally only sink floating refs if transfer-ownership=full. Thus, there is no need to add and remove an additional ref during closure marshalling and the GtkEntry in the example keeps its floating flag. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why keysym constants in gdk/gdkkeysyms.h are defined as macros, not as an enum?
On 27.06.2012 08:09, Tomeu Vizoso wrote: Well, using enums would make wrapping keysyms much easier on the gtkmm side. It will also help other bindings to stop doing things such as this: http://git.gnome.org/browse/pygobject/tree/gi/overrides/keysyms.py Why is this needed? The GDK_KEY_x constants are introspected properly and are available as Gdk.KEY_x. Changing the defines to enums would change the representation that gobject-introspection produces and would thus constitute a break of the IABI, as Colin called it -- the introspection ABI. The positive effects of such a change should therefore be significant enough to outweigh this downside. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On 07.10.2010 18:14, Federico Mena Quintero wrote: Is the list of annotations documented anywhere? This is the canonical place, as far as I know: http://live.gnome.org/GObjectIntrospection/Annotations. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On 06.10.2010 21:06, Federico Mena Quintero wrote: Is a boxed G_TYPE_STRV friendly enough to language bindings? Yes, I think so. It's pretty common for arguments and properties, so most bindings will be able to deal with it. With proper annotations, gobject-introspection can also represent it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On 06.10.2010 23:48, Federico Mena Quintero wrote: On Wed, 2010-10-06 at 22:32 +0200, Torsten Schoenfeld wrote: Yes, I think so. It's pretty common for arguments and properties, so most bindings will be able to deal with it. With proper annotations, gobject-introspection can also represent it. Excellent. Where are those annotations made? I grepped quickly in the gtk+ sources for other STRV properties, but didn't find anything that looked like an annotation for a automated generator... G_TYPE_STRV properties don't need annotations, they are handled automatically. But functions like your gtk_file_chooser_set_root_uris need to have annotations to tell gobject-introspection that 'char **roots' is actually a zero-terminated array. gtk_builder_add_objects_from_string in gtk+-3/gtk/gtkbuilder.c is an example with such an annotation. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_get_allocation
Cody Russell wrote: * gtk_widget_get_allocation Removed in 2.14.1 The prototype of this function was not agreed upon among the core developers. So the decision was deferred to the next Gtk version. It had to be removed before final API freeze, otherwise it could not have been changed anymore. This is rather old, but it never came up again after this so I'd like to see what thoughts are about how to implement this in C. It was in 2.13 but removed before 2.14 because of disagreement, but I can't find any public record of the disagreement in gtk-devel-list. Can anyone comment on what was not liked, or how a better implementation could be made? Here's the old discussion: http://bugzilla.gnome.org/show_bug.cgi?id=548052. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GLib testing framework
On Wed, 2007-11-07 at 09:15 -0500, Morten Welinder wrote: Note, that the filter should preserve line numbers, i.e., never remove and never insert newlines. Otherwise error messages with line numbers would drive you crazy. It could also just use #line pre-processor directives: http://gcc.gnu.org/onlinedocs/cpp/Line-Control.html -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How to deprecate PangoScript?
On Thu, 2007-08-02 at 15:48 -0400, Behdad Esfahbod wrote: 4. Like 3, but also go ahead and change PangoScript uses to GUnicodeScript in public Pango API (and internally too). This doesn't have the C++ problem because PangoScript and GUnicodeScript will be the same thing as far as the compiler is concerned. The gobject type name for PangoScript changes though as we should make pango_script_get_type() to just return g_unicode_script_get_type(). Right? As far as I can tell, option four won't cause insurmountable problems for language bindings. And given that it appears to be a clean solution from a C point of view, I think it's the winner. I take it that pango_script_iter_* won't be changed apart from pango_script_iter_get_range for which PangoScript is replaced by GUnicodeScript? -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Mon, 2007-06-18 at 09:55 -0300, Johan Dahlin wrote: void (* set_property)(GtkBuildable *buildable, GtkBuilder*builder, const gchar *name, const GValue *value); This collides with GObject::set_property. Maybe set_buildable_property? or buildable_set_property. I think C coders will dislike gtk_buildable_buildable_set_property. :-) Can you open a bug and set it as a blocker? Sure: http://bugzilla.gnome.org/show_bug.cgi?id=448928 -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Tue, 2007-06-12 at 18:26 -0300, Johan Dahlin wrote: gtkbuildable.h == GtkBuildable is an interface which is implementable to allow a GObject subclass to customize the behavior of how it is going to be built. Some of the GtkBuildable methods have very generic names which can become problematic for language bindings that support the usual method calling semantics. void (* set_name)(GtkBuildable *buildable, const gchar *name); const gchar * (* get_name)(GtkBuildable *buildable); These theoretically collide with GtkWidget::set_name and get_name. Fortunately though, as you say, GtkWidget overrides them to make both versions do the same. So no big problem here. void (* add) (GtkBuildable *buildable, GtkBuilder*builder, GObject *child, const gchar *type); This collides with GtkContainer::add. If you have an instance of GtkContainer, what should instance.add(...) resolve to? As an alternative, add_child() comes to mind. The name's not really GtkBuildable specific enough either, but at least it doesn't seem to collide with any existing method. void (* set_property)(GtkBuildable *buildable, GtkBuilder*builder, const gchar *name, const GValue *value); This collides with GObject::set_property. Maybe set_buildable_property? -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugs regarding late g_thread_init() calls
On Thu, 2007-01-04 at 09:25 -0500, Morten Welinder wrote: Note: if (!g_thread_supported ()) g_thread_init (NULL); bz! g_thread_supported called too early. g_thread_supported is actually a macro. It's another name for g_threads_got_initialized basically. So the idiom above should be safe, right? -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug with custom cell renderers in gtk-2.10.x
On Sat, 2006-10-21 at 21:19 +0100, Peter Clifton wrote: Is it a subclassed text-view? As I understand it, you have to implement the GtkCellEditable interface. (Or is it a custom renderer you need? - I can't remember). Yes, it is a sub-classed text view which adds a few methods and implements the GtkCellEditable interface. Well, it doesn't actually override any of the GtkCellEditable methods since that isn't necessary, it simply tells the GType system that it can be used as a cell editable. I wonder why vanilla GtkTextView doesn't do this. Anyway, in the application I observed the bug in, it was fixed by setting the height-request property on the text-view when it was created to do the editing. We set this to the height of the cell, which (give or take padding errors), appears to do the trick. Yep, that seems to fix the issue. Thanks. I still wounder if the text-view ought to specify a height-request which is big enough for at least one line though? Maybe. But what about cells that contain multiple lines? If the text view only requested enough pixels for one line, it'd still turn out to be too small and the workaround you describe above would still be needed. -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug with custom cell renderers in gtk-2.10.x
On Fri, 2006-10-20 at 22:20 +0200, Kristian Rietveld wrote: The patch doesn't seem to fix the reported issue. That is too bad. I could only reproduce this bug with gaim and with this fix it doesn't occur anymore. Richard doesn't see it anymore in Gossip. It would be great if you could provide us with a way to reliably reproduce this bug with the patch applied, so we can fix that case too. Oh, with reported issue I was referring to the issue with custom cell renderers that use a text view as the editable. The patch attached to the bugzilla bug doesn't seem to fix *that* issue. I can't comment on the pixbuf clipping issue. -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug with custom cell renderers in gtk-2.10.x
On Fri, 2006-10-20 at 16:16 +0200, Richard Hult wrote: It sounds like this one: http://bugzilla.gnome.org/show_bug.cgi?id=359231 There is a patch there which would be good to get tested in other apps besides Gossip. The patch doesn't seem to fix the reported issue. -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_ref_sink and GUnowned
On Thu, 2005-12-22 at 17:49 +0100, Tim Janik wrote: GtkObject derives from GUnowned This breaks the Perl bindings of GTK+. Our GTK+ bindings register GtkObject with our GLib bindings at start up. This involves associating it with the namespace Gtk2::Object and it usually also means setting up inheritance so that Gtk2::Object is a Glib::Object. For that, the GLib bindings look at the parent of the type and, if it is known to the bindings, put the associated namespace into Perl's inheritance mechanism. GInitiallyUnowned is not known to our GLib bindings, though, which results in Gtk2::Object having no ancestor. That in turn means that things like windows, containers, etc. are no Glib::Object -- they don't have access to, say, the signal and property API anymore. This breaks every non-trivial Gtk2-Perl program. Even if we added support for GInitiallyUnowned now, older versions of our bindings would still break if the underlying GLib is updated without also updating the bindings. Now, you could argue that our bindings should really walk up the whole ancestry until something known is reached instead of just looking at the direct parent. And I would probably agree; this has caused us problems in a different context as well. However, the current approach works with all combinations of GLib 2.[02468] and GTK+ 2.[02468]. The only thing it assumes is that the object hierarchy doesn't suddenly contain unknown types, which is, I think, a sensible assumption. For reference, the code that implements the described approach is in gperl_register_object: http://cvs.sourceforge.net/viewcvs.py/gtk2-perl/gtk2-perl-xs/Glib/GObject.xs?rev=1.53view=markup The GTK+ bindings use gperl_register_object (GTK_TYPE_OBJECT, Gtk2::Object) to register the type. -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: idea on gobject-introspection / gtk-doc metadata
On Wed, 2005-09-21 at 12:48 -0400, Tristan Van Berkom wrote: One thing I'd like to see introspectable is versioninig information on properties signals, right now the doc notes include Since 2.6 on function calls and such (it would also be nice to introspect whether properties, signals objects are depricated or not). I don't think properties and signals should be part of the introspection description at all since you can already find out everything you need by using the existing GObject / GType introspection support. Similarly, the values of GEnum and GFlags types don't need to be explicitly mentioned in the description -- all you need is the GType. -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
