Re: bugzilla cleanup
On Wed, Feb 6, 2013 at 9:24 AM, Matthias Clasen wrote: > On Tue, Feb 5, 2013 at 3:49 PM, Morten Welinder wrote: > >> >> Note, that there are other large parts of glib, such as gio, that >> have basically don't work on win32. And have five-year old >> patches in bugzilla. >> > > Getting win32 patches merged requires somebody with an interest in > GLib/GTK+ on that platform to step up and do patch review and > maintenance. I've never ever built anything on Windows, so I'm not > really in a position to review patches. Perhaps we should explore some new possibilities for getting these patches in. While I think many of us recognize the value of being cross-platform and even see it as a high priority for our stack, many of us (me included), just dont want to actuallypa run windows on our machines, or... if we use osx, prefer not to compile there. On the other hand we still have people willing to submit patches for bugs which crop up on these platforms. My initial thoughts are, is there any way to take a different strategy for reviewing patches on these platforms ? Perhaps (and this might be far fetched, I don't have much experience working with VMs so I couldn't say)... But perhaps it's possible to set up a battery of unit tests which can be run in a VM... one which can be a requirement for passing make check (or at least, make distcheck). If that could work, then we could at least require that, where possible, a regression test be provided with any submitted patch... proving that your patch passes the unit test could be a requirement to landing your patch. Otherwise, perhaps having a hand full of testimonies (even >= 2), from various users saying that the patch works for them, should be enough to land a given contribution... this would at least be better than stalling the platform completely (and might even help to attract someone that we can rely on to review win32 patches again, stalling the platform is certainly not helping). I'm not sure that this is exactly the right approach, but I think we need a technical solution to the problem, since we probably wont have someone from inside the community that we trust to review patches, who also wants to build and test on win32. But that is not to say there is no interest in win32, obviously submitted patches is proof that there is. Thoughts ? Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugzilla cleanup
On Tue, Feb 5, 2013 at 3:49 PM, Morten Welinder wrote: > > Note, that there are other large parts of glib, such as gio, that > have basically don't work on win32. And have five-year old > patches in bugzilla. > Getting win32 patches merged requires somebody with an interest in GLib/GTK+ on that platform to step up and do patch review and maintenance. I've never ever built anything on Windows, so I'm not really in a position to review patches. ___ 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 Tue, 2013-02-05 at 05:33 -0800, Simon Feltman wrote: > 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. Giovanni's diagnosis sounds right to me; it's pretty unfortunate that there's a transient state where the object is unreferenced. Besides the timeout approach, you could also use a thread? But I guess that's also racy since there's a window in which the python mutex is not held, but the native code has not yet added a ref. Possibly an approach where on (transfer full) input parameters, and we're recursing (i.e. we have a chain of python -> native -> python), defer the unrefs until the next outermost python is reentered. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugzilla cleanup
> It can be "easily fixed" in the sense that every application also would then > need to be fixed... Behdad, you're sitting in your ivory tower and throwing mud at suggested patches from people who suffer from this bug. What is the point of that? In the meantime, as Krzysztof points out, GOption simply doesn't work on Win32. I stand behind the original five-year old patch. The biggest complaint against that seems to be what to name one of the functions. Note, that there are other large parts of glib, such as gio, that have basically don't work on win32. And have five-year old patches in bugzilla. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugzilla cleanup
On Tue, Feb 5, 2013 at 11:27 AM, Behdad Esfahbod wrote: > On 02/05/2013 02:13 PM, Krzysztof Kosiński wrote: >> This bug, which makes GOption useless on Windows and has accumulated >> 93 comments so far, could be easily fixed (it has patches) if someone >> finally decided which way is preferable. > > It can be "easily fixed" in the sense that every application also would then > need to be fixed... I'm sorry if this is a naive perspective, but given that there seems to be no optimal solution at this point, is it possible to compromise? Could it be fixed by making an API change in the 3.x series? This would allow applications to fix it when/if they migrate and not mandate everyone gets on it ASAP. To me it seems like a less painful route, however, I am probably mistaken since this approach hasn't been adopted. Cheers, Josh ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugzilla cleanup
On 02/05/2013 02:13 PM, Krzysztof Kosiński wrote: > 2013/2/4 Matthias Clasen : >> Hi everybody, >> >> a while ago, we've talked about getting a handle on the enormous >> number of open bugs in glib and gtk. > > This bug, which makes GOption useless on Windows and has accumulated > 93 comments so far, could be easily fixed (it has patches) if someone > finally decided which way is preferable. It can be "easily fixed" in the sense that every application also would then need to be fixed... > https://bugzilla.gnome.org/show_bug.cgi?id=522131 -- behdad http://behdad.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugzilla cleanup
2013/2/4 Matthias Clasen : > Hi everybody, > > a while ago, we've talked about getting a handle on the enormous > number of open bugs in glib and gtk. This bug, which makes GOption useless on Windows and has accumulated 93 comments so far, could be easily fixed (it has patches) if someone finally decided which way is preferable. https://bugzilla.gnome.org/show_bug.cgi?id=522131 Regards, Krzysztof ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: quick question
On Tue, 2013-02-05 at 07:49 -0500, D.H. Bahr wrote: > is it possible to set an image as a background for a widget, say a > GtkEventBox? Broken since 3.3. See https://bugzilla.gnome.org/show_bug.cgi?id=672858 Regards, Peter Hurley ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: quick question
Thanks, I've been working around that using CSS.. El mar, 05-02-2013 a las 09:09 -0500, Peter Hurley escribió: > On Tue, 2013-02-05 at 07:49 -0500, D.H. Bahr wrote: > > is it possible to set an image as a background for a widget, say a > > GtkEventBox? > > Broken since 3.3. > > See https://bugzilla.gnome.org/show_bug.cgi?id=672858 > > Regards, > Peter Hurley > > ___ 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)
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
quick question
is it possible to set an image as a background for a widget, say a GtkEventBox? Best regards, D.H. Bahr ___ 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 29/01/13 11:44, Simon Feltman wrote: > It seems like the problem at hand can be solved by maintaining the > floating ref and adding our own safety ref for the wrapper. My impression was that floating references were purely for C convenience, and that interpreted languages with their own refcounting should be turning them into normal refs that can be reasoned about more easily. Shouldn't PyGObject rather be sinking *every* floating ref it sees? (Effectively, the Python wrapper would behave like a container, I suppose.) Then you'd have: (transfer none) function returning a pointer to a non-floating object: g_object_ref_sink() refs it; the wrapper now owns a normal ref. If you gtk_container_add() the wrapped object, the ref is no longer floating, so the container takes a new ref and the wrapper still owns the old ref. If the Python wrapper is destroyed, the C container still keeps the wrapped object alive. Good? (transfer none) function returning a pointer to a floating object: g_object_ref_sink() turns the floating ref into a normal ref. Proceed as above. Good? (transfer full) function returning a normal ref (as detected by g_object_is_floating() == FALSE): do nothing, the wrapper takes ownership of that ref. Proceed as above. Good? (transfer full) function returning a floating ref (as detected by g_object_is_floating() == TRUE): g_object_ref_sink() refs it, the wrapper now owns a normal ref. Proceed as above. Good? Pseudocode: def give_me_a_real_ref(function): if function.transfer_none: return g_object_ref_sink(function()) else: tmp = function() if g_object_is_floating(tmp): g_object_ref_sink(tmp) return tmp Or is that wrong? Regards, S ___ 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: bugzilla cleanup
On Mon, Feb 04, 2013 at 10:07:57AM -0500, Matthias Clasen wrote: > Just thought I should mention this, so nobody gets upset if their > favourite 10 year old bug is WONTFIXed... > With the recent xinput2 work, it would be nice to see this bug get fixed: https://bugzilla.gnome.org/show_bug.cgi?id=677329 https://mail.gnome.org/archives/gtk-devel-list/2012-December/msg00022.html The bug is caused by the xinput2 backend and is still in git (just tested today). Thanks! -- Ross Lagerwall ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
