Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
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: Touch selections
Hey Matthias, On jue, 2013-01-17 at 22:32 -0500, Matthias Clasen wrote: > Hey, > > I've now taken a look at the code, here are some impressions: > > GtkBubbleWindow looks interesting and somewhat similar to two things > that have been discussed: > a) a "PopupWindow" class to replace grabs (e.g. on wayland) > b) a "popover" widget that behaves like a transient overlay > (without being its own toplevel) > We should keep this private until we've worked out how it > overlaps/interacts with these usecases. Hmm, indeed, bubble window sits a bit between both. As for a), some aspects of the behavior defined in the whiteboard benefit from not having active grabs (especially the "selection is manipulable when popup is shown" bit), and otoh I think Wayland can't separate popup/grab behaviors. Making it more similar to b) sounds worthwhile. > > I'm not really convinced of some of the choices made in the > GtkSelectionWindow class: >a) a toolbar may not be the right container for what the designers > had in mind - there was some talk of scrolling Right, on earlier stages I also found myself wondering what could fit best here, the options seem to be: * Adding scrolling capabilities to toolbars * Making an entirely different widget Given the requirement for scrolling is somewhat artificial (popup would never be as wide as the screen) and that cramming enough items there is a symptom of usability disaster, the second option seemed too far stretched for the case. Probably an useless observation in the end, but I see similarities between GtkPathBar scrolling and how it should look/work here. >b) doesn't seem necessary to use a ui manager and actions here, > since you are not even allowing addition of actions >c) adding a public getter for the toolbar will make it impossible > for us to change the implementation strategy later I made it this way so this is parallel to ::populate-menu, from all possible compromises might have been the worst decision. As you mention below, GMenuModel seems the hip way to go, but those don't map to toolbars (Is there any rationale here? I seem to have missed this), the third option is exposing UIManager bits to allow merging, but I'm unsure about its life expectancy with GMenuModel in place. >d) I'm not convinced the special-casing of cut/copy/paste is really > worth it - I would just have added these action in > GtkEntry/GtkTextView > I recommend dropping this widget altogether for now, and just > construct the toolbar with the default actions directly in > GtkEntry/GtkTextView. I'm not against that, it struck me as slightly useful to have a default ordering/toolbar style for those, it could also be made private for those to use. > > In GtkEntry, I think the use of g_timeout_add_seconds for popping up > the selection is inappropriate - you don't want the delay to fluctuate > depending on whether you touch early or late in the second. Oh right, I'll change that > > It would be nice if we could reuse the ::populate-popup signals to > allow custom actions to be added; unfortunately, all existing users of > this signal expect to add menuitems to a menu. One possibility might > be to add a set_context_menu_model() function that takes a GMenuModel, > which could be used to populate the traditional context menu, or to > build something toolbar-like for your popup. Of course menumodel and > toolbar is not a perfect fit, either. And that last thing is the source of all dilemmas :) Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib 2.34 g_main_context_unref hangs
On 01/17/2013 02:48 PM, Ken Bass wrote: > On 01/17/2013 01:58 PM, Dan Winship wrote: >> g_main_context_default() does not give you a ref on the default context, >> so your code here is destroying an object internal to glib. If you call >> this more than once (or, if you do *anything* involving the default >> context after this point), I'd definitely expect it to fail. >> >> Beyond that, it's hard to say what you might be doing wrong without >> seeing more code. >> >> > Odd that it worked all these years Yeah, probably you were just lucky before... > For some reason I was under the impression it gave me a reference, > particularly because > when I look at that default context, its ref_count is 1, not 0. Right, it's created with a ref_count of 1 when you first call g_main_context_default(), but every time you call it after that, it just returns the same one again without reffing it. > My clean > up routine is the last thing executed before exit(), so > wouldn't this mean there is a memory leak? If you are only calling the cleanup routine once, then there shouldn't be any problem... is it possible you're freeing the GMainContext twice somehow? Anyway, there is no memory "leak" (because glib still has a pointer to the context, and could still return it it to you if you called g_main_context_default() again). There is just memory that is left unfreed on exit, which is not a bug. (OTOH, if you are valgrinding and trying to get rid of all possible leaks, it is useful to be able to free some of that stuff, and I know that freeing the default GMainContext immediately before exit *does* work, because all of the libsoup test programs do that. So, there may be something else going wrong in your code, like trying to free it twice or something.) -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib 2.34 g_main_context_unref hangs
On 01/18/2013 09:46 AM, Dan Winship wrote: On 01/17/2013 02:48 PM, Ken Bass wrote: On 01/17/2013 01:58 PM, Dan Winship wrote: g_main_context_default() does not give you a ref on the default context, so your code here is destroying an object internal to glib. If you call this more than once (or, if you do *anything* involving the default context after this point), I'd definitely expect it to fail. Beyond that, it's hard to say what you might be doing wrong without seeing more code. Odd that it worked all these years Yeah, probably you were just lucky before... For some reason I was under the impression it gave me a reference, particularly because when I look at that default context, its ref_count is 1, not 0. Right, it's created with a ref_count of 1 when you first call g_main_context_default(), but every time you call it after that, it just returns the same one again without reffing it. I might not have been clear here. I meant the reference count was still 1 right before program exit. My clean up routine is the last thing executed before exit(), so wouldn't this mean there is a memory leak? If you are only calling the cleanup routine once, then there shouldn't be any problem... is it possible you're freeing the GMainContext twice somehow? Yes, I only call the cleanup routine once. But I call: g_main_loop_unref(main_loop); g_main_context_unref(context); g_main_loop_unref() internally does unrefs the context (which should be the default context). So in essence the above is freeing it twice. What I thought was odd was that after the g_main_loop_unref() call, the ref_count of the context was still 1. Maybe I was confused and this was invalid memory left over from before the unref/free that I am seeing in gdb. Anyway, there is no memory "leak" (because glib still has a pointer to the context, and could still return it it to you if you called g_main_context_default() again). There is just memory that is left unfreed on exit, which is not a bug. (OTOH, if you are valgrinding and trying to get rid of all possible leaks, it is useful to be able to free some of that stuff, and I know that freeing the default GMainContext immediately before exit *does* work, because all of the libsoup test programs do that. So, there may be something else going wrong in your code, like trying to free it twice or something.) I am pretty certain that my reason for freeing this many years ago was due to valgrind analysis and cleanup. You say that you know freeing the default GMainContext works, does the libsoup test do both the g_main_loop_unref(main_loop); g_main_context_unref(default_context); If so, that is no different that what I am doing, which would appear to be a double unref. Thanks for your help. I ended up just checking if I was dealing with the default context and if so, do not unref it since I do not own it. That works fine and does make sense. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
