Re: GUI freeze and long blocking operation
On Fri, Jun 14, 2013 at 8:28 AM, Kip Warner k...@thevertigo.com wrote:
On Thu, 2013-06-13 at 08:59 +0100, jcup...@gmail.com wrote:
Hi Kip,
Hey John,
There are two easy ways to do a long operation in Python.
First, with idle_add(). Your callback should run for no more than 50ms
or so before returning. If you need to do more work than that, just
wait to be called again. Do not process events, you can leave that up
to the main loop. This style is handy for non-blocking, background
tasks that don't need interaction from the user.
Ok, fair enough. I didn't know idle callbacks were intended to be used
only for fast non-blocking tasks.
Secondly, with a regular loop that takes control for a long period.
You can keep the GUI alive by processing events, as you say above.
This style is better for modal actions that either block the GUI or
may require interaction.
So as I mentioned I tried abandoning the idle_add() approach and instead
relied on calling the worker function directly.
It sounds like you have done both at the same time, which seems
confusing to me. I'd make a pure 2) one. If the GUI doesn't refresh,
you probably have a bug in your code somewhere.
I do this by calling the long job function directly from within the
GtkAssistant's prepare signal callback immediately. The problem is
that the GUI doesn't refresh throughout the duration of the long job,
even though I do explicitly pump the message queue by calling
_updateGUI() method regularly:
Kip,
Let me try to illustrate what you need to do to make this work.
What you currently have is:
~
prepare_signal_callback ()
{
/* Update the GUI and flush the event queue, only once, at the
beginning of your operation */
while (gtk_events_pending())
gtk_main_iteration_do ();
/* Process some data that takes a long time, without ever again
updating the GUI */
while (there_is_data)
process_data();
}
What you need to do instead is:
~~~
prepare_signal_callback ()
{
/* Do your huge intensive loop that takes a long time */
while (there_is_data)
{
/* Process a chunk of your long data operation */
process_only_a_little_bit_of_data();
/* Every once and a while, during your huge task, be friendly
to the user and show
* some feedback, i.e. update the GUI often enough so that
things appear to run smoothly.
*/
while (gtk_events_pending())
gtk_main_iteration_do ();
}
}
What you seem to be missing, is that GTK+ doesnt update itself in a
separate thread, your program
by default is single threaded and can only be processing data or
updating the GUI at a given time,
but not both.
If you have to call a function in a proprietary library which you
cannot modify, and that function
atomically takes a long time, the only way to keep the GUI responsive
during that time is to
add your own worker thread to call the function, and then signal the
main thread when the
operation completes (usually by queuing a g_idle_add() at the end of
your worker thread
so that the completion notification callback is queued to execute in
the main GUI thread).
Cheers,
-Tristan
# Update the GUI...
def _updateGUI(self):
# Update GUI...
(...)
# Flush the event queue so we don't block...
while Gtk.events_pending():
Gtk.main_iteration()
The GUI just appears to hang on the previously displayed page in the
assistant and doesn't advance to the one that actually should be visible
following the prepare signal callback.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GUI freeze and long blocking operation
On Fri, 2013-06-14 at 15:08 +0900, Tristan Van Berkom wrote:
On Fri, Jun 14, 2013 at 8:28 AM, Kip Warner k...@thevertigo.com wrote:
On Thu, 2013-06-13 at 08:59 +0100, jcup...@gmail.com wrote:
Hi Kip,
Hey John,
There are two easy ways to do a long operation in Python.
First, with idle_add(). Your callback should run for no more than 50ms
or so before returning. If you need to do more work than that, just
wait to be called again. Do not process events, you can leave that up
to the main loop. This style is handy for non-blocking, background
tasks that don't need interaction from the user.
Ok, fair enough. I didn't know idle callbacks were intended to be used
only for fast non-blocking tasks.
Secondly, with a regular loop that takes control for a long period.
You can keep the GUI alive by processing events, as you say above.
This style is better for modal actions that either block the GUI or
may require interaction.
So as I mentioned I tried abandoning the idle_add() approach and instead
relied on calling the worker function directly.
It sounds like you have done both at the same time, which seems
confusing to me. I'd make a pure 2) one. If the GUI doesn't refresh,
you probably have a bug in your code somewhere.
I do this by calling the long job function directly from within the
GtkAssistant's prepare signal callback immediately. The problem is
that the GUI doesn't refresh throughout the duration of the long job,
even though I do explicitly pump the message queue by calling
_updateGUI() method regularly:
Kip,
Let me try to illustrate what you need to do to make this work.
What you currently have is:
~
prepare_signal_callback ()
{
/* Update the GUI and flush the event queue, only once, at the
beginning of your operation */
while (gtk_events_pending())
gtk_main_iteration_do ();
/* Process some data that takes a long time, without ever again
updating the GUI */
while (there_is_data)
process_data();
}
Hey Tristan. I see what you mean, but I think I should have provided
more code to show that what I was actually doing I think was what your
followup suggestion was. Namely do some short work, update the GUI, do
some more short work, repeat.
http://pastebin.com/DzrT7Fa7
So line 140 is the prepare signal callback which calls the long job
startDiscVerification(). The latter is a long job which repeatedly calls
_calculateChecksum(). But during each call to the latter, _updateGUI()
is called which pumps the message queue.
--
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Invisible GtkImage
On Thu, Jun 13, 2013 at 9:54 PM, Kip Warner k...@thevertigo.com wrote: What you can do to (try to) prevent that situation is to set the widget to do height for width allocation, and override get_preferred_height_for_width() to honor your aspect ratio. In some situations of course the toolkit won't be able to perfectly honor the allocation request, so be sure not to scale out of bounds no matter what. Right. What I will do is resize to exactly what is passed into my do_size_allocate() override since that size should theoretically meet the aspect ratio I am maintaining via my do_get_preferred_height_for_width() override. def do_get_preferred_height_for_width(self, width): return (width / self._aspectRatio) def do_get_request_mode(self): return Gtk.SizeRequestMode.HEIGHT_FOR_WIDTH ...but something very interesting happens immediately after the return in do_get_preferred_height_for_width(). I get an assertion fail buried deep somewhere in python-gi... I suspect something weird is happening because you have the wrong function signature. I can't find any reference to the basic widget methods on the python gtk documentation website, but the C signature is: voidgtk_widget_get_preferred_height_for_width (GtkWidget *widget, gint width, gint *minimum_height, gint *natural_height); So try: def do_get_preferred_height_for_width(self, width, minimum_height, natural_height): minimum_height = width / self._aspectRatio natural_height = width / self._aspectRatio If that doesn't work, try and find out how the python gintrospection stuff deals with out parameters. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK free function doesn't appear to have any affect.
I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? e.g. -- gtk_list_store_clear (store); g_object_unref( G_OBJECT (store) ); g_object_unref ( G_OBJECT ( col_renderer [j] )); Same goes with GtkBuilder structures. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On Fri, Jun 14, 2013 at 12:27 AM, dE de.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? e.g. -- gtk_list_store_clear (store); g_object_unref( G_OBJECT (store) ); g_object_unref ( G_OBJECT ( col_renderer [j] )); Do you have a treeview that is internally holding a reference to the list store? I don't know about the GtkBuilder structures. Also, g_new uses g_slice internally sometimes, and that will do things like try to cache pages I think. Be sure to set the G_SLICE environment variable to always-malloc when monitoring your memory usage. See [1] [1] https://developer.gnome.org/glib/2.36/glib-running.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On 06/14/13 13:24, Andrew Potter wrote: On Fri, Jun 14, 2013 at 12:27 AM, dE de.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? e.g. -- gtk_list_store_clear (store); g_object_unref( G_OBJECT (store) ); g_object_unref ( G_OBJECT ( col_renderer [j] )); Do you have a treeview that is internally holding a reference to the list store? I don't know about the GtkBuilder structures. Also, g_new uses g_slice internally sometimes, and that will do things like try to cache pages I think. Be sure to set the G_SLICE environment variable to always-malloc when monitoring your memory usage. See [1] [1] https://developer.gnome.org/glib/2.36/glib-running.html Before I unref and clear the ListStore I'm running gtk_tree_view_set_model (GtkTreeView *, NULL) on the TreeModel. However there's a GtkTreeModelSort which holds the ListStore, this GtkTreeModelSort is then added to the TreeView. I didnt find a way to unset the GtkTreeModelSort and the ListStore, but before I clear and unref the ListStore, I unref the GtkTreeModelSort. gtk_tree_view_set_model ( ddisplay , NULL ); //unref to the TreeModelSort g_object_unref ( G_OBJECT ( inter_sort ) ); gtk_list_store_clear (store); g_object_unref( G_OBJECT (store) ); Setting export G_SLICE=always-malloc did nothing. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GUI freeze and long blocking operation
On 14 June 2013 07:29, Kip Warner k...@thevertigo.com wrote: Hey Tristan. I see what you mean, but I think I should have provided more code to show that what I was actually doing I think was what your followup suggestion was. Namely do some short work, update the GUI, do some more short work, repeat. http://pastebin.com/DzrT7Fa7 From a quick look your code ought to work. I've written stuff very like this which works fine. I think you'll need to make a complete example I can try running, sorry. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
eclipse problem
I this is the wrong list, but I am active here... so why not start here While editing the project C/C++ Build settings I somehow got the window to shrink horizontally to be a single vertical bar. If I hit ESC the window closes. The edges won't drag Anyone seen this before? Tom ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On Fri, Jun 14, 2013 at 3:27 AM, dE de.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? What are you monitoring, and how ? It is i normal that freeing memory does not change the resource consumption of the process. The freed memory will be available for reuse by malloc, but malloc does not immediately return the memory to the OS. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On 06/14/13 17:02, Matthias Clasen wrote: On Fri, Jun 14, 2013 at 3:27 AM, dE de.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? What are you monitoring, and how ? It is i normal that freeing memory does not change the resource consumption of the process. The freed memory will be available for reuse by malloc, but malloc does not immediately return the memory to the OS. So I'll try allocating like 7GB of memory to fill up the ram, after finishing, it should free. I'll report back. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On Sat, Jun 15, 2013 at 12:23 AM, dE de.tec...@gmail.com wrote: On 06/14/13 17:02, Matthias Clasen wrote: On Fri, Jun 14, 2013 at 3:27 AM, dE de.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? What are you monitoring, and how ? It is i normal that freeing memory does not change the resource consumption of the process. The freed memory will be available for reuse by malloc, but malloc does not immediately return the memory to the OS. So I'll try allocating like 7GB of memory to fill up the ram, after finishing, it should free. I'll report back. For more fine grained memory profiling you should use valgrind. See some hints here for running your Glib program with valgrind: https://live.gnome.org/Valgrind Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On 06/14/13 17:02, Matthias Clasen wrote: On Fri, Jun 14, 2013 at 3:27 AM, dE de.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? What are you monitoring, and how ? It is i normal that freeing memory does not change the resource consumption of the process. The freed memory will be available for reuse by malloc, but malloc does not immediately return the memory to the OS. No, filled more than 7GB, swap was at ~350 MB, and then I loaded a small table which would otherwise take less than 10 MB memory, but the memory usage increased. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On 06/14/13 21:14, Tristan Van Berkom wrote: On Sat, Jun 15, 2013 at 12:23 AM, dE de.tec...@gmail.com wrote: On 06/14/13 17:02, Matthias Clasen wrote: On Fri, Jun 14, 2013 at 3:27 AM, dE de.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? What are you monitoring, and how ? It is i normal that freeing memory does not change the resource consumption of the process. The freed memory will be available for reuse by malloc, but malloc does not immediately return the memory to the OS. So I'll try allocating like 7GB of memory to fill up the ram, after finishing, it should free. I'll report back. For more fine grained memory profiling you should use valgrind. See some hints here for running your Glib program with valgrind: https://live.gnome.org/Valgrind Cheers, -Tristan http://forums.gentoo.org/viewtopic-t-961762.html Do we have no other options? Like some kind of 'code sanitizer' which detects flaws in code related to memory? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On Fri, 14 Jun 2013 21:41:05 +0530 dE de.tec...@gmail.com wrote: On 06/14/13 17:02, Matthias Clasen wrote: On Fri, Jun 14, 2013 at 3:27 AM, dE de.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? What are you monitoring, and how ? It is i normal that freeing memory does not change the resource consumption of the process. The freed memory will be available for reuse by malloc, but malloc does not immediately return the memory to the OS. No, filled more than 7GB, swap was at ~350 MB, and then I loaded a small table which would otherwise take less than 10 MB memory, but the memory usage increased. Can you post the smallest compilable program which demonstrates your problem (run with G_SLICE=always-malloc set), and with particulars of how you are measuring memory usage? That should identify if you are doing something wrong with how you are handling the memory in your program. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On 06/14/13 22:09, Chris Vine wrote: On Fri, 14 Jun 2013 21:41:05 +0530 dEde.tec...@gmail.com wrote: On 06/14/13 17:02, Matthias Clasen wrote: On Fri, Jun 14, 2013 at 3:27 AM, dEde.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? What are you monitoring, and how ? It is i normal that freeing memory does not change the resource consumption of the process. The freed memory will be available for reuse by malloc, but malloc does not immediately return the memory to the OS. No, filled more than 7GB, swap was at ~350 MB, and then I loaded a small table which would otherwise take less than 10 MB memory, but the memory usage increased. Can you post the smallest compilable program which demonstrates your problem (run with G_SLICE=always-malloc set), and with particulars of how you are measuring memory usage? That should identify if you are doing something wrong with how you are handling the memory in your program. Chris You can have the whole source code: http://pastebin.com/4a5DiMsQ I'd been distributing it around to fix issues. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On Sat, Jun 15, 2013 at 2:33 AM, dE de.tec...@gmail.com wrote: On 06/14/13 22:09, Chris Vine wrote: On Fri, 14 Jun 2013 21:41:05 +0530 dEde.tec...@gmail.com wrote: On 06/14/13 17:02, Matthias Clasen wrote: On Fri, Jun 14, 2013 at 3:27 AM, dEde.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? What are you monitoring, and how ? It is i normal that freeing memory does not change the resource consumption of the process. The freed memory will be available for reuse by malloc, but malloc does not immediately return the memory to the OS. No, filled more than 7GB, swap was at ~350 MB, and then I loaded a small table which would otherwise take less than 10 MB memory, but the memory usage increased. Can you post the smallest compilable program which demonstrates your problem (run with G_SLICE=always-malloc set), and with particulars of how you are measuring memory usage? That should identify if you are doing something wrong with how you are handling the memory in your program. Chris You can have the whole source code: http://pastebin.com/4a5DiMsQ I'd been distributing it around to fix issues. dE, Surely you can conjure something small which you expect not to leak memory, but does. Obviously, there must be a leak in this program, but sending us this huge file sort of implies that we should do the debugging and find your memory leak for you. If you send us something small, as Chris says: the smallest compilable program which demonstrates your problem, then we can surely easily spot the problem and guide you on how to fix it, without spending our time doing your homework. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On Fri, 14 Jun 2013 23:03:55 +0530 dE de.tec...@gmail.com wrote: On 06/14/13 22:09, Chris Vine wrote: On Fri, 14 Jun 2013 21:41:05 +0530 dEde.tec...@gmail.com wrote: On 06/14/13 17:02, Matthias Clasen wrote: On Fri, Jun 14, 2013 at 3:27 AM, dEde.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? What are you monitoring, and how ? It is i normal that freeing memory does not change the resource consumption of the process. The freed memory will be available for reuse by malloc, but malloc does not immediately return the memory to the OS. No, filled more than 7GB, swap was at ~350 MB, and then I loaded a small table which would otherwise take less than 10 MB memory, but the memory usage increased. Can you post the smallest compilable program which demonstrates your problem (run with G_SLICE=always-malloc set), and with particulars of how you are measuring memory usage? That should identify if you are doing something wrong with how you are handling the memory in your program. Chris You can have the whole source code: http://pastebin.com/4a5DiMsQ I'd been distributing it around to fix issues. This isn't going to help I am afraid. On some general observations on your earlier questions however: A GtkBuilder object is a plain GObject. It will be freed by calling g_object_unref() on it. That will also cause it to release its references to the objects it has created. Whether that will destroy those created objects depends on whether there are any other references to them which have been acquired, such as by their having been put in a container. If so, then you need to release those other references as well in order to destroy the created objects and free their memory. Top level windows need to have gtk_widget_destroy() called on them. If you want to remove a widget from a container or top level window but keep the container or top level window alive, you can cause the container to release its reference with gtk_container_remove(). If you want all containers holding a reference to a particular GtkWidget to release their references so leading to the widget's destruction, call gtk_widget_destroy() on the widget. For plain GObjects, namely those which are not created with a floating reference (and so are not derived from GInitiallyUnowned/GtkWidget), to free them you need to have called g_object_unref() on them explicitly as well as destroy (or remove them from) their container (if any): except that GtkBuilder will already have done that for you if it supplies a plain GObject already embedded in a container it has supplied. For objects derived from GInitiallyUnowned/GtkWidget, destroying (or removing them from) their container by one of the means mentioned above is enough. You may be aware of all that. If so I am afraid you need to break your code down to see whether you have discovered a referencing bug (not likely but possible - I have reported referencing bugs before now), or you have neglected to release something somewhere. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Invisible GtkImage
On Fri, 2013-06-14 at 00:17 -0700, Andrew Potter wrote: I suspect something weird is happening because you have the wrong function signature. I can't find any reference to the basic widget methods on the python gtk documentation website, but the C signature is: voidgtk_widget_get_preferred_height_for_width (GtkWidget *widget, gint width, gint *minimum_height, gint *natural_height); So try: def do_get_preferred_height_for_width(self, width, minimum_height, natural_height): minimum_height = width / self._aspectRatio natural_height = width / self._aspectRatio Hey Andrew. You're quite right. My override was implemented wrong. However, I think the problem was not in the in parameters, but in the out parameters. The input parameters I think were correct, but the caller is expecting a two-tuple back out. get_preferred_height_for_width(self, width:int) - minimum_height:int, natural_height:int When I fixed that, it doesn't core dump anymore. I just return the same value for both fields. I have three concerns. The first is that sometimes the incoming allocation has some very strange width and height values in it, but are usually valid the rest of the time. Sometimes I see values like width of -408563232 and height of 32767. My second concern is that when the assistant window is resized to be made larger horizontally, the image grows, as it should, but the bottom of the assistant page with the usual assistant buttons (e.g. Cancel, Continue) get clipped some how. Clipping: http://www.zimagez.com/zimage/screenshot-13-06-14-051057pm.php No clipping: http://www.zimagez.com/zimage/screenshot-13-06-14-051249pm.php My final concern is I'm worried about the introspection system's error control on handling bad return signatures the way it did here. Since the introspection data knows that the method should have provided two out parameters, you'd think it would have caught this more gracefully with an exception than a core dump? But I guess that's probably nothing you or I can do about that right now. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GUI freeze and long blocking operation
On Fri, 2013-06-14 at 10:22 +0100, jcup...@gmail.com wrote: From a quick look your code ought to work. I've written stuff very like this which works fine. Hey John. Yeah, I'm stumped too. I think you'll need to make a complete example I can try running, sorry. Coming up with a minimal for you could be difficult, but I'll try that as a last resort. Maybe you have some debugging tips? I'm finding it hard to debug in Python compared to all the many frontends to GDB for native code. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Invisible GtkImage
On Fri, Jun 14, 2013 at 5:20 PM, Kip Warner k...@thevertigo.com wrote: I have three concerns. The first is that sometimes the incoming allocation has some very strange width and height values in it, but are usually valid the rest of the time. Sometimes I see values like width of -408563232 and height of 32767. That's unusual. Quick testing of my own image resizing does not seem to have that occur. If you're sure that your requests are always absolutely sane, you might want to put together a small test case as it could indicate a pygtk bug, or maybe a gtk+ bug. My second concern is that when the assistant window is resized to be made larger horizontally, the image grows, as it should, but the bottom of the assistant page with the usual assistant buttons (e.g. Cancel, Continue) get clipped some how. Is your TextView set to have a minimum height? My final concern is I'm worried about the introspection system's error control on handling bad return signatures the way it did here. Since the introspection data knows that the method should have provided two out parameters, you'd think it would have caught this more gracefully with an exception than a core dump? But I guess that's probably nothing you or I can do about that right now. I suspect it has more to do with Python's dynamic typing. But you might raise the issue with the pygtk folks [1]. [1]: https://mail.gnome.org/mailman/listinfo/python-hackers-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Invisible GtkImage
On Fri, 2013-06-14 at 18:17 -0700, Andrew Potter wrote: That's unusual. Quick testing of my own image resizing does not seem to have that occur. If you're sure that your requests are always absolutely sane, you might want to put together a small test case as it could indicate a pygtk bug, or maybe a gtk+ bug. It could be a bug, but in my experience, it's probably the developer's fault (me). But I'll try to look into it further if I get a chance. In the mean time, I'll have to be content with... if allocation.width = 0 or allocation.height = 0: return Is your TextView set to have a minimum height? So the bad news is I tried setting a minimum height for the TextView and no love. But the good news is I changed the do_get_preferred_height_for_width() override to return a value of 1 for the minimum_height... def do_get_preferred_height_for_width(self, width): height = width / self._aspectRatio # Return the minimum height and natural height... return 1, height I'm still not sure what exactly the minimum_height is for, or if leaving it at 1 is going to be a problem, but the clipping issue seems fine and the image rescales _almost_ fine now. If I advance the assistant page to the next one, however, the image is no longer scaled uniformly, but is squished at only half the height it was while maintaining the same width. I suspect it has more to do with Python's dynamic typing. But you might raise the issue with the pygtk folks [1]. Done. Thanks. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK free function doesn't appear to have any affect.
On 06/14/13 23:14, Tristan Van Berkom wrote: On Sat, Jun 15, 2013 at 2:33 AM, dE de.tec...@gmail.com wrote: On 06/14/13 22:09, Chris Vine wrote: On Fri, 14 Jun 2013 21:41:05 +0530 dEde.tec...@gmail.com wrote: On 06/14/13 17:02, Matthias Clasen wrote: On Fri, Jun 14, 2013 at 3:27 AM, dEde.tec...@gmail.com wrote: I was monitoring the memory usage before and after execution of g_object_unref and gtk_list_store_clear, and it didnt change the memory usage by a bit. Is this normal (am I doing it right?)? What are you monitoring, and how ? It is i normal that freeing memory does not change the resource consumption of the process. The freed memory will be available for reuse by malloc, but malloc does not immediately return the memory to the OS. No, filled more than 7GB, swap was at ~350 MB, and then I loaded a small table which would otherwise take less than 10 MB memory, but the memory usage increased. Can you post the smallest compilable program which demonstrates your problem (run with G_SLICE=always-malloc set), and with particulars of how you are measuring memory usage? That should identify if you are doing something wrong with how you are handling the memory in your program. Chris You can have the whole source code: http://pastebin.com/4a5DiMsQ I'd been distributing it around to fix issues. dE, Surely you can conjure something small which you expect not to leak memory, but does. Obviously, there must be a leak in this program, but sending us this huge file sort of implies that we should do the debugging and find your memory leak for you. If you send us something small, as Chris says: the smallest compilable program which demonstrates your problem, then we can surely easily spot the problem and guide you on how to fix it, without spending our time doing your homework. Cheers, -Tristan So I'll make a large GtkTreeStore, and try to free it. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
