Re: Pygobject memory leak in set_property?
On Fri, Jan 2, 2015 at 1:29 PM, Colin Myers colin.my...@tabernus.com wrote: Yes, the memory increase is in proportion with the size of the text. But it is more likely to be an error in my understanding than a pygobject or gtk bug – this is usually the case… This is a memory leak in pygobject. Lots leaks were fixed in get_property() last release [1] but set_property() still needs work [2]. -Simon [1] https://bugzilla.gnome.org/show_bug.cgi?id=726999#c7 [2] https://bugzilla.gnome.org/show_bug.cgi?id=735018 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkglarea 2.1.0 released
On Fri, May 9, 2014 at 5:01 AM, Javier Jardón jjar...@gnome.org 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
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: Gdk 3.4.1
Hi, The migration guide should help you along if you have not already found it: https://developer.gnome.org/gtk3/3.4/gtk-migrating-2-to-3.html Specifically the expose-event signal has been replace with GtkWidget::draw. -Simon On Sat, Jul 20, 2013 at 10:52 PM, Chris Sparks mr_...@cox.net wrote: Hello, I have been search and search for an answer to my dilemma so I thought I'd post a question here. If this isn't the right list, please advise. I have been using Gdk 2.x for some time and decide to upgrade to Gdk 3.x. Let me tell you that it has been and continues to be a nightmare. However, I have been noticing that I am not getting any Expose events even though my app is looking at all events. (Via ALL_EVENTS_MASK). Has Expose events been deprecated? I noticed Client Events have changed too and I have to deal with that one too. Any help greatly appreciated. chris sparks __**_ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/**mailman/listinfo/gtk-app-**devel-listhttps://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to call WebKit.DOMDocument.evaluate function in python
Hi, On Mon, Jul 1, 2013 at 11:48 PM, Niranjan Rao nhr...@gmail.com wrote: I need to perform some DOM operations once the document is loaded. Webkit DOMDocument provides evaluate method which can allow me to reach to element using xpath, if it works. The parameter DOMXPathResult of the evaluate method has annotations declared in such a way that null/None value in python can not be used. However null value in this case is legal and accepted. It looks like the introspection bindings are missing (allow-none) for the parameter. The bindings seem to be generated by a perl script and a quick web search revieled a related problem here: https://bugs.webkit.org/show_bug.cgi?id=42115 You should probably log a bug against WebKit Gtk to get the annotation fixed. Also, have you tried creating an empty WebKit.DOMXPathResult and passing that? res = WebKit.DOMXPathResult() Is there any way to get underlying gobject pointer from python so that I can use ctypes and try to call function directly. So far my attempts have resulted in coredump as webkit is asserting on various values I am sending to it. Later versions of PyGObject give access to the internal GObject pointer through the __gpointer__ attribute on wrapped objects. But it is unclear if this would be useful in ctypes because it returns a PyCapsule. This attribute is used internally for some parts of PyGObject. However, we cannot support this officially as it is an implementation detail, so use at your own risk. You should also be able to create a small C extension to Python which wraps the function up for you. -Simon ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to call WebKit.DOMDocument.evaluate function in python
On Tue, Jul 2, 2013 at 10:35 AM, Niranjan Rao nhr...@gmail.com wrote:
And yes, I had tried creating empty WebKit.DOMXPathResult object and
passing it. Did not work.
It would be helpful to know the details of what didn't work. Code examples
of what you have tried, or steps to reproduce the problems you are seeing
can be invaluable for getting help. A simple example on my system shows
using an empty DOMXPathResult is actually working:
In [1]: from gi.repository import WebKit
In [2]: view = WebKit.WebView()
In [3]: dom = view.get_dom_document()
In [4]: dom.evaluate('/', dom, WebKit.DOMXPathNSResolver(), 0,
WebKit.DOMXPathResult())
Out[4]: DOMXPathResult object at 0x7fc670b08eb0 (WebKitDOMXPathResult at
0x2ea90f0)
This is with PyGObject/GTK+ version 3.8.2 (not sure about WebKit version).
If this does not work with older versions, supporting a fallback with
ctypes hacks sounds reasonable. This would allow support for older versions
while ensuring use of proper API on newer versions. If the __gpointer__
attribute is not available or not useful, you can still find the pointer to
the GObject by using offsets of the pointer field on the PyGObject wrapper.
But code examples of what you have already tried will be needed to further
aid you with this.
-Simon
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to call WebKit.DOMDocument.evaluate function in python
Ah, that's good news. Happens to me sometimes as well when trying to
translate C docs to Python :) Sometimes Python's help can be your friend
help(WebKit.DOMDocument.evaluate)
On Tue, Jul 2, 2013 at 5:12 PM, Niranjan Rao nhr...@gmail.com wrote:
Simon,
Thanks for the pointer. I noticed that I made a stupid mistake and was
sending document as a first parameter.
Your example opened my eyes and now it looks like its running ok.
Thanks,
Niranjan
On 07/02/2013 02:37 PM, Simon Feltman wrote:
On Tue, Jul 2, 2013 at 10:35 AM, Niranjan Rao nhr...@gmail.com wrote:
And yes, I had tried creating empty WebKit.DOMXPathResult object and
passing it. Did not work.
It would be helpful to know the details of what didn't work. Code
examples of what you have tried, or steps to reproduce the problems you are
seeing can be invaluable for getting help. A simple example on my system
shows using an empty DOMXPathResult is actually working:
In [1]: from gi.repository import WebKit
In [2]: view = WebKit.WebView()
In [3]: dom = view.get_dom_document()
In [4]: dom.evaluate('/', dom, WebKit.DOMXPathNSResolver(), 0,
WebKit.DOMXPathResult())
Out[4]: DOMXPathResult object at 0x7fc670b08eb0 (WebKitDOMXPathResult
at 0x2ea90f0)
This is with PyGObject/GTK+ version 3.8.2 (not sure about WebKit
version). If this does not work with older versions, supporting a fallback
with ctypes hacks sounds reasonable. This would allow support for older
versions while ensuring use of proper API on newer versions. If the
__gpointer__ attribute is not available or not useful, you can still find
the pointer to the GObject by using offsets of the pointer field on the
PyGObject wrapper. But code examples of what you have already tried will be
needed to further aid you with this.
-Simon
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: style_get_property giving wrong answer?
Hi, Are you using C or Python? If this is specific to Python, there is a bug logged for it here: https://bugzilla.gnome.org/show_bug.cgi?id=701058. Is your mention of gtk_widget_get_property a mistake? as it should be gtk_widget_style_get_property in the C API. -Simon On Fri, Jun 28, 2013 at 11:58 AM, Conscious User consciousu...@gmail.comwrote: I'm using gtk_widget_get_property to get the toggle-spacing of a GtkMenuItem. However, it seems to be returning 0 even though, visually, the spacing is clearly non-zero. What could be causing this? This is happening in Ubuntu 13.04 (GTK 3.6), and didn't happen in previous versions. Does not seem to happen with other style properties either. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Updating GUI during long operation
On Fri, Apr 26, 2013 at 6:16 AM, Colomban Wendling lists@herbesfolles.org wrote: That's weird. However, although I don't know much about Python threading (and another guy in this thread suggests it's not really good), I'm wondering whether your thread couldn't be simply locking stuff used by both GUI and worker thread, effectively blocking the GUI one. To clarify, Python threading is probably the wrong tool for CPU bound operations unless those operations free up the GIL. On Fri, Apr 26, 2013 at 5:05 PM, Kip Warner k...@thevertigo.com wrote: Thanks Nicola. For some reason, and perhaps this is just coincidental, but I've noticed the GUI seems fully responsive since I exchanged GObject.idle_add() for Gdk.threads_add_idle()? I wonder why, or if that's just coincidental and my machine is just better behaved today for an unrelated reason. Unless the GDK/GTK calls within the callback scheduled by GObject.idle_add are explicitly surrounded with Gdk.threads_enter/leave() along with a call Gdk.threads_init() at program start, then chances are the problems you ran into are related to GDK/GTK calls not being thread safe and the callback not holding the GDK global lock. As Nicola mentioned, Gdk.threads_add_idle does this for you. Also note that Gdk.threads_enter/leave are essentially no-ops unless Gdk.threads_init is called. My confusion regarding these APIs stems from some of them being marked as deprecated since version 3.6 (Gdk.threads_init and Gdk.threads_enter/leave). In this case it is unclear whether or not Gdk.threads_init is still necessary when using Gdk.threads_add_idle with GTK+ = 3.6. -Simon ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Updating GUI during long operation
On Sat, Apr 20, 2013 at 4:25 PM, Kip Warner k...@thevertigo.com wrote: http://rod.gs/Sio A brief look at the source and it seems there is nothing calling Gdk.threads_init which I think is needed. Similarly, use Gdk.threads_add_idle instead of GObject.idle_add for scheduling GUI updates from worker threads. The necessity of these is still somewhat unclear to me at the moment though. Enough questions have come up recently with Python and GTK+ threading that I've added a wiki page here: https://live.gnome.org/PyGObject/Threading This is very much a work in progress and I appreciate updates or validation if you find any of this useful. The threading model in Python is pretty bad and you might consider a different technique (please read up on the Python GIL if you don't already know how threading in Python works). If the operation is IO bound, look into using async IO with Gio. If it is CPU bound, take a look at the Python processing module or even numpy for certain things. These techniques will make the app much more responsive because other threads won't be blocked by the GIL. A surprising example is as follows: sum(range(100)) This seems to completely block any other Python threads for the entirety of the operation. I think the reason is because the GIL is held the whole time and Python is not giving time to other threads for the duration of the call (this includes GTK+ update callbacks written in Python). If you split the operation up, you can gain interactivity with other threads because Python will interleave statement execution with giving time to other threads (at the cost of performance). total = 0 for i in range(0, 100, 100): ... total += sum(range(i, i + 100)) In this sense Python is really always single threaded in regards to running pure Python code in which none of the statements ever release the GIL (IO related functions should be fine though). And if there are not any calls which release the GIL, Python threads might just be adding overhead and confusion. Finally, the same example using numpy will allow the same operation to run completely unblocked by the GIL in its own thread, so you keep full interactivity with actual concurrent processing of the threads (and the operation is about 10 times faster than the first example). numpy.sum(numpy.arange(100)) -Simon ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-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 kaffeeti...@gmx.dewrote: 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
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 otay...@redhat.com 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 kaffeeti...@gmx.dewrote: 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-**listhttps://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 s.felt...@gmail.com 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 kaffeeti...@gmx.dewrote: 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-**listhttps://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)
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)
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 t...@gnome.org wrote: On Tue, Feb 5, 2013 at 12:08 PM, Simon Feltman s.felt...@gmail.com 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 kaffeeti...@gmx.de 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 s.felt...@gmail.com 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)
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 kaffeeti...@gmx.dewrote: 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-**listhttps://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)
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 s.felt...@gmail.com 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 t...@gnome.orgwrote: On Fri, Jan 18, 2013 at 5:49 AM, Giovanni Campagna scampa.giova...@gmail.com 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
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: Best way to busy-wait in Python 3 / Gtk+ 3?
On Sun, Oct 7, 2012 at 9:10 PM, Michael Torrie torr...@gmail.com wrote: Maybe the best way is to avoid processes or threads altogether. Since downloading this thumbnail is io-bound, not cpu-bound, once you send off your request, just use io watches to trigger the main loop when something has come in. Agreed, better yet, the code could become much simpler using an async pixbuf: def on_image_ready(stream, res, user_data): pixbuf = GdkPixbuf.Pixbuf.new_from_stream_finish(res) ... file = Gio.File.new_for_uri(...) GdkPixbuf.Pixbuf.new_from_stream_async(file.read(None), None, on_image_ready, None) All within a main loop of course. -Simon ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Best way to busy-wait in Python 3 / Gtk+ 3?
On Sun, Oct 7, 2012 at 12:29 PM, Filip Lamparski matka.pooha...@gmail.com wrote: On 7 October 2012 12:58, jcup...@gmail.com wrote: To have the load in another process, use a pipe to send worker results back to the main process, and add the pipe to your gtk main loop as an event source. Is there any way I could do that? I looked at GLib's main loop and Gtk's main loop, but can't seem to find it. Is the idea to have a first pass downloading image files in a separate process and then use a thread to load them into memory? I don't know much about GStreamer but it seems like it might be helpful technology in this realm. For completeness, you can use pythons multiprocessing module along with GLib's io watch: parent, child = multiprocessing.Pipe() GLib.io_add_watch(parent, GLib.IOCondition.IN, event_callback) process = multiprocessing.Process(target=worker_func, args=(child,)) process.start() -Simon ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-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 y...@physics.muni.cz 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
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 t...@gnome.org wrote: On Sun, Jul 22, 2012 at 6:20 AM, John Emmas john...@tiscali.co.uk 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: Implementing a custom signal with PyGObject
Hi Moritz, A good thing to do would be to pair your example down into something runnable from a console without any dependencies except GObject and Gtk if possible. Anyone helping will have to do this anyway in order to observe the problem. However, something that immediately stuck out in the code, and I'm not sure if it's a problem, is deriving from both Gtk.Button and GObject.GObject. I don't think this is needed because GObject is already a parent class of Gtk.Button. -Simon On Fri, Jul 6, 2012 at 9:26 AM, Moritz Renftle rueckmeld...@renftle.netwrote: hi! i'm trying to create a custom signal for a file-selection-button, code is here: http://bpaste.net/show/DZwtKCPDBcpCv0g0NQCn/ the problem: when the signal is emitted in the image_selection-method, it doesn't call the connected signal handler, if this handler is not within the same class. but if i connect the signal with a method in the same class, it works. is this a pygi-related bug or am i doing something wrong? thanks in advance, moritz ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: problems understanding gtk3/gdk/cairo interaction
You should be able to just fill the delta regions between the cursor position changes right? Basically a backwards L shape if you're dragging upper-left to lower-right. You would need to do two rect copies (or two calls to gtk_widget_queue_draw_area for each part of the L) as opposed to one. If items have a visible selected state that changes as you drag, then the regions for those items should simply be invalidated (but only if their state changes) along with the rubber band regions using gtk_widget_queue_draw_area. On Thu, Apr 12, 2012 at 1:20 PM, Roger Davis r...@soest.hawaii.edu wrote: Hi John and Simon, OK, experiment complete. Performance for me is very clearly not as good as Xlib-style XOR when drawing rubberband lines which span a screen-sized window (which is more or less typical for my apps, unfortunately), but on the other hand it's not unusable either, just somewhat annoyingly jerky. With smaller drawing areas (e.g., 300x300) the rubberbanding is perfectly smooth. Playing around with motion hint events might clean this up a little more. I'm basically doing a cairo_rectangle()/cairo_fill() from my entire off-screen surface to the GtkDrawingArea after every MotionNotify event. There are special cases, e.g., small rectangular rubberband boxes, where this is horrific overkill, but I also have cases where I need to rubberband larger collections of unpredictably-oriented line segments which span the full window, so I think my worst-case scenario experimental implementation has been a reasonable test. The outcome could have been worse, and I was expecting that it would be! For now I'll tell my users to wait 5 years and then buy new hardware. ;- Thanks for all your suggestions! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
