Re: Fully winding down my involvement in GTK+
It does not really matter how developer discussions take place as long as they are documented and searchable. Transparency of reasoning behind decisions is just as important as the decision for anyone trying to understand the code base. For medium and large development, I advocate for something like pythons PEPs. For smaller stuff, I see nothing wrong with grabbing chunks of IRC or mailing list discussions and copying them into bug reports or just using the bug report for the discussion (the bug number/url/pep can then be referenced as a comment in the code). -Simon On Sun, Jul 22, 2012 at 11:23 AM, Tristan Van Berkom wrote: > On Sun, Jul 22, 2012 at 6:20 AM, John Emmas wrote: > > On 22 Jul 2012, at 02:14, Michael Torrie wrote: > > > >> > >> I consider web-based forums to be the scourge of the internet. > >> > > > > Curiously, that's exactly how I feel about mailing lists. Mailing lists > work well as long as the volume of traffic is relatively low. They > probably also work well if you're a dedicated user who's willing to install > and configure an email client that supports them. But once they start > becoming busy, mailing lists become a turn-off for the average user who > doesn't want that level of sophistication and doesn't need to be involved > in most of the discussions. > > > > Taking myself as an example... during the past 3 years I've probably > signed up to 30 mailing lists. Today, only 3 of those subscriptions are > still active. I've unsubscribed from the other 27. > > > > Conversely, I've never unsubscribed from a web forum. There are plenty > of forums that I use only rarely - but I've never unsubscribed from one. I > still feel a connection to the relevant community, even if I rarely use it. > But I don't feel any connection at all to a community once I've > unsubscribed from its mailing list. > > > > So if the aim is to make users feel more engaged / more connected, I > don't believe that mailing lists are helpful. In fact, if that's what > you're trying to achieve I'd go as far as saying that mailing lists are > actually a hindrance. Whilst they can (and do) build a strong sense of > community between developers and the more dedicated users, the high volume > of traffic (which often isn't of much interest to the more casual user) > makes them feel irrelevant and excluded. That's been my experience anyway. > > No I don't think that is the aim at all. > > The point is about developers, not users. Mailing lists are the only > proven way I know of > for coherently developing a product with many developers in many time > zones. > > This point is critical, after that... with remaining efforts left over > from developing said > software, or by the efforts of other unrelated contributors: help > forums and better > documentation can be written... none of that happens without the first > thing though, > i.e. the software being written by the developers who communicate on a > mailing list. > > Support for users need not be delivered in the form of a mailing list, > but since there are > mailing lists for them... no reason to take that away from them > either... I'm sure there > are some user forums for GTK+ out in the wild as well. > > Cheers, > -Tristan > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
Toggle buttons and the switch widget both suffer usability problems for me. The visual look of a button represents an action to be performed in my mind, perhaps why it was referred to it as a soft-action? So when a button is stateful it can create ambiguity depending on the text of the button. The old, "Does it perform the action shown on the label or does the label reflect the current state?" This causes dissonance in my mind which can hopefully be resolved by the widget having another visual indication of the state (the depressed look). A typical example of this failure is with Glades usage of toggle buttons on a selected widgets properties (don't mean to offend anyone here, just stating my experience!). This is further confused by the text changing when you press the button to Yes or No. Moving on to the switch widget, I think it mostly suffers the same issues I've described. Does the text on the switch widget represent the current state or the action of setting the state to on or off. Again the visual indication barely saves me here (having it highlighted to blue). Given this, the visual indication aside from the text is what I use to determine the state of either a toggle or switch. This makes me think the text on the widget only confuses things and the widget could simply be a checkbox which would resolve all visual ambiguity. However, I do see value in what is described in the UX guidelines regarding the switch widget and associating it with things that take time (not just a simple checkbox state). The guidelines also don't describe explicit styling of the switch which is my problem with it. I think the visual ambiguity could easily be fixed by showing both available states, looks like it is already being discussed here: https://bugzilla.gnome.org/show_bug.cgi?id=644658 -Simon On Sat, Aug 4, 2012 at 8:47 AM, David Nečas wrote: > On Sat, Aug 04, 2012 at 03:39:05PM +0100, Emmanuele Bassi wrote: > > one implies a "soft" action (GtkToggleButton), whereas the other > > implies something similar of a hardware switch (GtkSwitch). > > As every user knows, widgets relay wishes to magic pixies. I wonder if > that is soft or hard action, maybe it depends on how hard you need to > beat the pixies to do what you want. > > Do you actually expect different kinds of on/off controls to be mixed > wildly because each was selected based on how soft is the action it > implies? > > > they both > > have their use cases which are not interchangeable: > > > > https://live.gnome.org/GnomeOS/UX/Guidelines/SwitchWidget > > > > the page above should become part of the new Human Interface > > guidelines/design patterns. not every application should use switches, > > nor existing applications should be mindlessly migrated to moving from > > toggle and/or check buttons to switches. > > All cases listed there as good use cases of GtkSwitch would be – for me > – improved by using a plain toggle button. > > It would take less horizontal space, it would be less wordy, it would > not leave me wondering whether it shows ON when it is on or whether I > should move it to ON if I want it ON (yes, I still do not remember it), > it would not look trendy, and it would not have translation issues. In > fact, even the ‘wrong’ checkbuttons would represent an improvement for > me. > > I would also say the widgets are completely interchangeable, but forced > to interpret the statement ‘their use cases are not interchangeable' > somehow I would have to conclude that GtkSwitch has no meaningful use > case at all. Could the page be improved to include this? In my opinion > it could lead to a considerable simplification of the guidelines. > > > the short takeaway is that the switch should be used in specific > > cases, and that the way its been defined as a widget does not allow > > inheritance from GtkToggleButton or GtkButton (no label, no children, > > styling of trough and handle). > > I am sorry but, again, this is just a recapitulation of the status quo. > Stating it a hundered times does not make problems vanish magically even > if you beat the pixies really hard with a switch. > > Yeti > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
Hi Everyone, I'm trying to figure out a complete solution for proper reference management of gobjects passed into python vfuncs and signal closures as "in" arguments. Currently pygobject will add a ref to gobject arguments marked as transfer-none during marshaling and additionally sink/ref the gobject when the python object wrapper is created around it. The initial added ref during marshaling is then leaked upon the closure finishing in most cases. The fix could simply be to not add the initial ref during marshaling (or we need to make sure it is released when the closure finishes). The problem is this behavior is relied upon when a floating ref is passed and is the explicit fix described in the following ticket (which un-fortunately causes a leak in the non-floating case): https://bugzilla.gnome.org/show_bug.cgi?id=661359 The specific problem described in bug 661359 occurs when a python closure is connected to a GtkCellRendererTexts "editing-started" signal. During the start of editing, a GtkEntry is created and passed almost immediately to signal emission before any ownership takes place: http://git.gnome.org/browse/gtk+/tree/gtk/gtkcellrenderer.c#n864 This results in the following ref counting behavior of the GtkEntry as it is used by gtk_cell_area_activate_cell and gtk_cell_renderer_start_editing: 1 (floating) - gtk_cell_renderer_text_start_editing creates the GtkEntry 2 (floating) - g_signal_emit argument marshaling adds an additional ref during signal emission 3 (floating) - python closure marshaling adds an additional ref described above 3 (owned) - A PyGObject wraps the GtkEntry and sinks the floating ref * python callback is called and passed the wrapper 2 (owned) - The PyGObject wrapper is destroyed after the python callback finishes additionally freeing a gobject ref 1 (owned) - g_signal_emit argument marshaling completes and frees the ref it added 2 (owned) - gtk_cell_area_activate_cell sets the CellAreas edit widget which adds a ref 1 (owned) - cell editing finishes and removes the widget from the CellArea Given the above it seems cell editing will leak a new editor each time editing occurs even if no closures are connected to the "editing-started" signal (python or otherwise). 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). However, the root cause of all this could simply be that cell editing needs better reference management of the editors being created. For instance, gtk_cell_renderer_text_start_editing creates the GtkEntry and stores it as an attribute in GtkCellRendererText.priv.entry without sinking the ref: http://git.gnome.org/browse/gtk+/tree/gtk/gtkcellrenderertext.c#n2049 I think this should be changed to immediately sink the ref and unref it during gtk_cell_renderer_text_editing_done. This would solve the python problems and fix the reference leak for the editor (and bug 661359 can be backed out). Additionally I think gtk_cell_area_set_edit_widget should be sinking the incoming editable widget instead of simply adding a ref: http://git.gnome.org/browse/gtk+/tree/gtk/gtkcellarea.c#n3309 As a general practice shouldn't refs be sunk when they are being assigned to a structured attribute especially when dealing with GInitiallyUnowned based objects? Insight into any of this is greatly appreciated. -Simon ___ 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 tend to agree we should be avoiding reliance on main loops (or GC timing) to get the ref counts right if possible. PyGObject also uses toggle refs similarly to gjs for keeping the wrappers alive. However, in PyGObject this only happens if a Python instance attribute is set. Whereas with gjs it seems to use a toggle ref all the time just in case an attribute is set? It seems like the problem at hand can be solved by maintaining the floating ref and adding our own safety ref for the wrapper. With one caveat: upon completion of the python callback we may consider sinking the GObject if the ref is floating and the Python wrapper has a reference count greater than one. This basically means code in the callback made an assignment of the object to something outside of its scope and that should be considered a strong reference. But that might not even be necessary. I've attempted to describe this along with all the other problematic reference counting situations in a separate document: https://live.gnome.org/PyGObject/Analysis/ObjectReferenceCountingForVFuncsAndClosures The biggest concern at this point is how to properly deal with vfunc implementations which return objects and are annotated as "transfer none". Review, corrections, and feedback is very welcome. Thanks, -Simon On Fri, Jan 18, 2013 at 12:19 AM, Tristan Van Berkom wrote: > On Fri, Jan 18, 2013 at 5:49 AM, Giovanni Campagna > wrote: > [...] > > I know that Python doesn't have a GC in the traditional sense, but you > > could still send finalization for GObject wrappers to a idle callback > > so there is no risk of finalizing objects that C code assumes are > > still alive. > > That doesn't sound like a very safe workaround to me. > > There are situations where a lot of code can run without the mainloop > ever becoming idle, while running a ClutterTimeline is one of those > cases (or at least I've observed that idle callbacks dont generally > get called while a ClutterTimeline is playing, perhaps they do with > an ultra high priority). > > Another thing to consider is that not all code written with the glib > stack is actually reactive & event based, code that does not run > a mainloop will risk blowing up in size quickly, possibly attaining > out of memory conditions unnecessarily if the code happens to > be highly recursive. > > Cheers, > -Tristan > ___ 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)
After some deliberation and writing a bunch of tests: http://git.gnome.org/browse/pygobject/commit/?id=97f48f 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. The reason I think this will work is because libraries that make use of InitiallyUnowned are designed to deal with the floating refs already. Python is basically a thin wrapper used to tie objects together within these systems and never needs to maintain ownership beyond making sure the underlying object is kept alive while the wrapper is alive. From this, we can rely on the internals of the libraries to do the right thing and sink floating references where they normally would in C usage. If they don't, it is most likely a bug in C as well (by convention). This seems like it will solve all of the current problems and special casing during marshaling. However, it also adds a leak for the most basic (and useless) case: for i in range(10): Gtk.Button() This would leak the initial floating ref and the memory would be lost. However, I can't think of a real use case where something like that would ever be needed. The alternatives to can become grossly convoluted: https://bugzilla.gnome.org/show_bug.cgi?id=687522#c15 Thoughts? -Simon On Tue, Jan 29, 2013 at 3:44 AM, Simon Feltman wrote: > I tend to agree we should be avoiding reliance on main loops (or GC > timing) to get the ref counts right if possible. > > PyGObject also uses toggle refs similarly to gjs for keeping the wrappers > alive. However, in PyGObject this only happens if a Python instance > attribute is set. Whereas with gjs it seems to use a toggle ref all the > time just in case an attribute is set? > > It seems like the problem at hand can be solved by maintaining the > floating ref and adding our own safety ref for the wrapper. With one > caveat: upon completion of the python callback we may consider sinking the > GObject if the ref is floating and the Python wrapper has a reference count > greater than one. This basically means code in the callback made an > assignment of the object to something outside of its scope and that should > be considered a strong reference. But that might not even be necessary. > I've attempted to describe this along with all the other problematic > reference counting situations in a separate document: > > https://live.gnome.org/PyGObject/Analysis/ObjectReferenceCountingForVFuncsAndClosures > > The biggest concern at this point is how to properly deal with vfunc > implementations which return objects and are annotated as "transfer > none". Review, corrections, and feedback is very welcome. > > Thanks, > -Simon > > > > On Fri, Jan 18, 2013 at 12:19 AM, Tristan Van Berkom wrote: > >> On Fri, Jan 18, 2013 at 5:49 AM, Giovanni Campagna >> wrote: >> [...] >> > I know that Python doesn't have a GC in the traditional sense, but you >> > could still send finalization for GObject wrappers to a idle callback >> > so there is no risk of finalizing objects that C code assumes are >> > still alive. >> >> That doesn't sound like a very safe workaround to me. >> >> There are situations where a lot of code can run without the mainloop >> ever becoming idle, while running a ClutterTimeline is one of those >> cases (or at least I've observed that idle callbacks dont generally >> get called while a ClutterTimeline is playing, perhaps they do with >> an ultra high priority). >> >> Another thing to consider is that not all code written with the glib >> stack is actually reactive & event based, code that does not run >> a mainloop will risk blowing up in size quickly, possibly attaining >> out of memory conditions unnecessarily if the code happens to >> be highly recursive. >> >> Cheers, >> -Tristan >> > > ___ 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 could easily be misunderstanding the internals, but at some point isn't a call to something like gtk_widget_set_parent on the children needed for widgets to ever be displayed or useful? (which sinks the children) If it really might be a problem we could work around the leak by tracking if the instance was created within python and if the instance has ever been marshaled to C. At which point we could rely on the GC cleanup of the wrapper to sink and unref the extra ref in cases the GObject was never passed on to C at any point. This sucks but it seems a little better than checking GObject ref counts during marshaling and floating sunk objects based on if it was initially floating and the GObject ref count is only 1, which might be unsafe. -Simon On Mon, Feb 4, 2013 at 4:56 AM, Torsten Schoenfeld wrote: > 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<https://mail.gnome.org/mailman/listinfo/gtk-devel-list> > ___ 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)
The side affect of GtkWindow is actually fine in this case because the annotation of "transfer none" for gtk_window_new makes sense here. The function is specifying it returns an internal borrowed reference and Python will add an additional ref during the wrappers lifetime. However, there is trouble when using g_object_new(GTK_TYPE_WINDOW) because it is annotated as "transfer full" which means the constructor is giving us full ownership of that internal reference and without some type of special case, the language binding wrappers will free that internal reference. The cleanest fix would be for gtk_window_new to specify transfer full along with sinking and adding an additional ref before returning, this would at least give consistency between g_object_new(GTK_TYPE_WINDOW) and gtk_window_new in terms of how introspection based bindings see it. But this is most likely out of the question. Instead it will take some combination of tracking and testing things like: is derived from InitiallyUnowned, is it floating, are we calling a constructor, and what is the ownership transfer. And then try to make a best guess as to what we are supposed to do. -Simon On Mon, Feb 4, 2013 at 11:05 PM, Tristan Van Berkom wrote: > On Tue, Feb 5, 2013 at 12:08 PM, Simon Feltman > wrote: > > I could easily be misunderstanding the internals, but at some point > isn't a > > call to something like gtk_widget_set_parent on the children needed for > > widgets to ever be displayed or useful? (which sinks the children) > > One of the more gross internal details of GTK+ is that GtkWindows > (any toplevel widgets) get added to an internal 'list of toplevels'. > > So a GtkWindow is an odd subclass that (like someone else > pointed out), sinks it's own floating reference at initialization time. > > The ownership of the window is virtually given to "GTK+" and then > disposed of automatically at gtk_widget_destory() time. > > I suppose that strictly speaking, an object constructor can indeed > have side effects (but I can't think of any case where it would be > anywhere close to 'sane' to intentionally use object constructors > for their side effects and ignore the results). > > Best, > -Tristan > > > > > If it really might be a problem we could work around the leak by > tracking if > > the instance was created within python and if the instance has ever been > > marshaled to C. At which point we could rely on the GC cleanup of the > > wrapper to sink and unref the extra ref in cases the GObject was never > > passed on to C at any point. This sucks but it seems a little better than > > checking GObject ref counts during marshaling and floating sunk objects > > based on if it was initially floating and the GObject ref count is only > 1, > > which might be unsafe. > > > > -Simon > > > > > > > > On Mon, Feb 4, 2013 at 4:56 AM, Torsten Schoenfeld > > wrote: > >> > >> 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 > > > > > > > > ___ > > gtk-devel-list mailing list > > gtk-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > ___ 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)
This is basically how PyGObject works now. There are no problems with this during casual usage when Python is always in the position of the "caller". The problem is this scheme does not work with the marshaling of floating widgets passed into Python vfuncs/closures as arguments or intended as return values from them. I just added a bunch of commentary to the following bug about why it is failing: https://bugzilla.gnome.org/show_bug.cgi?id=657202#c21 ___ 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)
For completeness, the two major problems are as follows:
https://bugzilla.gnome.org/show_bug.cgi?id=687522
This is a vfunc implementation which the gtk internals are basically
expecting a floating ref from. Using the standard scheme just listed, we
sink and own the created MenuToolButton. The held widget is then finalized
at the end of the vfunc, returning an invalid object back to the caller. If
we add an extra ref we get a leak because the method is marked as
transfer-none. Example:
class ToolMenuAction(Gtk.Action):
def do_create_tool_item(self):
return Gtk.MenuToolButton()
https://bugzilla.gnome.org/show_bug.cgi?id=661359
This is a very simple case of a widget as a parameter being marshaled as an
in arg to a callback. But because the gtk internals have not yet sunk the
floating ref for the "editable" parameter, PyGObject will do so. By the
time the callback is finished, the editable will be finalized leaving gtk
with a bad object. It should really just be adding a safety ref during the
lifetime of the wrapper and not mess with the floating flag.
def on_view_label_cell_editing_started(renderer, editable, path):
print path
renderer = Gtk.CellRendererText()
renderer.connect('editing-started', on_view_label_cell_editing_started)
-Simon
On Tue, Feb 5, 2013 at 5:09 AM, Simon Feltman wrote:
> This is basically how PyGObject works now. There are no problems with this
> during casual usage when Python is always in the position of the "caller".
> The problem is this scheme does not work with the marshaling of floating
> widgets passed into Python vfuncs/closures as arguments or intended as
> return values from them. I just added a bunch of commentary to the
> following bug about why it is failing:
> https://bugzilla.gnome.org/show_bug.cgi?id=657202#c21
>
>
>
___
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)
Owen,
Thank you, this will definitely make things easier. Comments below:
* Floating references are C-convenience only
>
It might be a convenience for writing code, not necessarily reading or
understanding it. Something more reasonable would be explicitly
named convenience functions which steal a ref instead of adding one. But
that may only be an alternate reality at this point.
* Languages can and should sink floating references when they
>first touch them.
>
> * Any interface or code in libraries that create problems with
>this are buggy.
>
I will submit bug reports and patches where applicable.
This has been the view from day 1, and I think you'll create
> considerably bigger problems trying to futz around with it and treat
> floating references specially in a binding than you have now.
>
Agreed.
The only thing I can see at the GTK+ level would be to add a
> make_tool_item replacement vfunc and use that instead if non-null.
> There's a workaround at the application level, which is something like:
>
> def do_create_tool_item(self):
> button = Gtk.MenuToolButton()
> self.buttons.append(button)
> button.connect('destroy', self.remove_from_buttons)
>
> return button
>
> we can document this bug in the gtk-doc and suggest the workaround
> there. But I'd strongly suggest *not* doing wholesale changes to the
> Python memory management based on this bug.
>
Docs will help, we can also detect the bad situation and assert giving some
explanation to minimize support load and keep future maintainers from
trying to fix it again. Would something like the following be safe in
regards to testing the GObject ref count?
assert !(transfer == nothing && pyobject->ref_count == 1 &&
gobject->ref_count ==1)
This means the Python wrapper is only held in the out args tuple and will
be free'd when the closure is finalized, deleting the gobject along with it
and giving back a bad object. We could also add an additional ref to the
gobject and throw up a nasty warning.
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)
> def on_view_label_cell_editing_started(renderer, editable, path):
> >
> > print path
> > renderer = Gtk.CellRendererText()
> > renderer.connect('editing-started',
> > on_view_label_cell_editing_started)
>
> This one is is simple. GTK+ needs to sink the arg before calling the
> function. There should be no compatibility problems. The pygi patch on
> the bug appears simply wrong and probably is creating the leak you
> noticed.
>
Yes, definitely a leak. However, fixing it will break people again. So the
gtk bug needs to be fixed first. There is also no telling how many of these
there are without looking through all vfuncs/signals which take a widget as
an input arg with transfer=none.
Thanks,
-Simon
___
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 Wed, Feb 6, 2013 at 12:57 PM, Owen Taylor wrote: > > > class ToolMenuAction(Gtk.Action): > > def do_create_tool_item(self): > > > > return Gtk.MenuToolButton() > > This is basically broken API at the GTK+ level :-( ... a virtual > function can't return (transfer none) unless it's a getter for an > existing field. It is expected that language bindings will have no way > to create a floating object, so a virtual function cannot expect to be > returned a floating object. > > The only thing I can see at the GTK+ level would be to add a > make_tool_item replacement vfunc and use that instead if non-null. > I don't know GTK+ internals but taking a quick look are you saying to use the "_gtk_reserved" pointers for new vfuncs and annotate them as transfer full? A potential issue is the API which wraps this is also marked as transfer none (gtk_action_create_tool_item) and the code that calls this is all setup to receive a floating ref that it sinks, changing it seems like it would be an API break. In any case if gtk_action_create_tool_item starts returning an already sunk object, it will leak. This could be hacked around by doing a force_floating on the results of the vfunc and then gtk_action_create_tool_item will continue to maintain the same expected floating results. But is this kind of thing acceptable? If it is we might not even need to use the reserved pointers but just start mark the existing vfunc as transfer full and then force the result as floating? -Simon ___ 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'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. Thanks, -Simon On Thu, Feb 7, 2013 at 1:16 PM, Torsten Schoenfeld wrote: > 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<https://mail.gnome.org/mailman/listinfo/gtk-devel-list> > ___ 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)
Ticket and patch for the transient argument to the GtkCellRendererText "editing-started" signal: https://bugzilla.gnome.org/show_bug.cgi?id=693400 This is what I was proposing when I started this thread. If this kind of fix is ok, I have no problem looking for more cases in the GTK+ code base. Thanks, -Simon On Thu, Feb 7, 2013 at 7:08 PM, 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. > > Thanks, > -Simon > > > > On Thu, Feb 7, 2013 at 1:16 PM, Torsten Schoenfeld wrote: > >> 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<https://mail.gnome.org/mailman/listinfo/gtk-devel-list> >> > > ___ 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 Fri, Feb 8, 2013 at 3:05 AM, Torsten Schoenfeld wrote: > Won't gobject-introspection silently turn the (transfer full) annotation > into (transfer none) due to the special handling for GInitiallyUnonwed > descendants? > It seems to pick it up correctly. The problem was actually the rename annotation doesn't work for vfuncs. Also, the list in the bug is missing Gtk.CellRenderer.start_editing (the > vfunc, not the method). Ack, sorry, I will add an additional note. -Simon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Proposal: Default Constructors in GI
Hi All, In an effort to cleanup the Python bindings, I have been auditing the plethora of overrides to see what can be removed [1]. There are a handful of cases where the binding machinery could handle things given more information from GI as opposed to binding overrides. Specifically, overridden methods like constructors (__new__ in Python). The proposal is to add meta data attributes to various classes which describe what to use for default construction. This would be particularly useful in cases where g_object_new is invalid and may even crash (singletons and GBinding for example). These problems definitely threw me off when I first started learning GI and I have dealt with a number of related tickets since, hence this proposal. I attempted some analysis by following classes without public constructors [2] and created a tracking ticket for related issues [3]. The idea is to introduce two annotations for classes: "factory" and "constructor", either as first class annotations or as generic attribute annotations. The concept of a "factory" applies to object creation for an entire class hierarchy and requires a type as the first argument for dispatching. The "constructor" annotation can then override the factory for class specific creation where needed. The primary usage of the factory annotation is to fix problems related to GInitiallyUnowned class hierarchies used with g_object_new (which is marked as transfer-full but may return a floating reference). Example annotation as follows: /** * GObject: * Attributes: (meta.factory GObject.Object.new) **/ /** * GInitiallyUnowned: * Attributes: (meta.factory GObject.InitiallyUnowned.new) **/ This introduces a new factory function designed for GInitiallyUnowned and any sub-classes. g_initially_unowned_newv would wrap g_object_newv but with the return marked as transfer-none (or transfer-floating). This gives bindings the correct information to use g_object_ref_sink on the result. This would allow us to remove the special case hacks in bindings which use g_object_newv for generically creating all objects (checking if the class is GInitiallyUnowned or is floating and sinking accordingly). While the hacks really aren't such a big deal, this gives a concise way bindings should interpret GI and allow for purer GI bindings. Default constructor annotations hint that the class should not use the factory, but instead use the specified class constructor (overrides the class hierarchies factory for this specific class): /** * GVolumeMonitor: * ... * Attributes: (meta.constructor GObject.VolumeMonitor.get) * ...or to not allow construction... * Attributes: (meta.constructor GObject.private_constructor_error) **/ Note that this must be restricted to the class it is called on (cannot be used for sub-classes). For this reason, it is important to distinguish the annotations for factory and constructor creation. For Python, standard object creation of Gio.VolumeMonitor() would then give back the singleton instance (the machinery will call "get"). Or as noted in the example, marking construction private which would give an error. private_constructor_error being a function which takes and fills out a GError resulting in an exception for interpreted languages. So in this case, calling Gio.VolumeMonitor() would raise an exception with something like: "direct creation of class is not allowed, please read the class documentation." This will help relieve support tickets. Classes which have required constructor arguments but no way to specify this [4] can use a default constructor annotation with an explicit function that requires the arguments: /** * GtkTreeModelFilter: * Attributes: (meta.constructor Gtk.TreeModelFilter.new)...requires child_model and root arguments... **/ Additional Thoughts: * The names used for the attribute annotations are initial suggestions. * I am a little biased towards using "Attributes:" as opposed to adding first class annotations because: ** It will be easier. ** Bindings don't have to rely on new GI API and can still work with older versions of GLIb/GTK+ as they always have. * We should not add default constructor annotations to classes which are already working with g_object_new because it might break things. Only add constructor annotations to classes which are already broken or require overrides to dispatch to the appropriate constructor. Feedback appreciated. -Simon [1] https://bugzilla.gnome.org/show_bug.cgi?id=705810 [2] https://wiki.gnome.org/PyGObject/Analysis/Bug675581 [3] https://bugzilla.gnome.org/showdependencytree.cgi?id=708060 [4] https://bugzilla.gnome.org/show_bug.cgi?id=649662 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkglarea 2.1.0 released
On Fri, May 9, 2014 at 5:01 AM, Javier Jardón wrote: > I already pushed a branch in the git repository with the GTK+3 port [1] > ... > [1] https://git.gnome.org/browse/gtkglarea/log/?h=jjardon/gtk3 This branch is working well for me. I've created a ticket and patch [1] adding introspection support. A basic demo using PyGI, GtkGL, and PyOpenGL can be found here [2]. > I also plan to change the namespace [2] of the api to not conflict > with future GTK+ work on this. Not sure if it is related, but for the introspection patch I used the namespace GtkGL (classes named GtkGL.Area and GtkGL.Context) by adding some extra g-ir-scanner flags. Thanks! -Simon [1] https://bugzilla.gnome.org/show_bug.cgi?id=729902 [2] https://github.com/sfeltman/pygobject/blob/demos/demos/gtk-demo/demos/OpenGL/scene.py ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
