Re: GUI freeze and long blocking operation
Hi Kip, On 13 June 2013 06:40, Kip Warner k...@thevertigo.com wrote: If I start the long job function from within my assistant's prepare signal callback, as opposed to en-queueing it there via idle_add(), then the GUI doesn't refresh throughout the duration of the long job. This happens even though I do pump the message queue during the long job via the usual... while Gtk.events_pending(): Gtk.main_iteration() 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. 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. 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. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Fwd: Attention: State propagation changed in master, themes may need changes
forwarding to gtk-list and gtk-app-devel-list, to reach a wider audience. remember: discussions about gtk development (which include themes) happen on gtk-devel-list. ciao, Emmanuele. -- Forwarded message -- From: Alexander Larsson al...@redhat.com Date: 13 June 2013 11:46 Subject: Attention: State propagation changed in master, themes may need changes To: gtk-devel-l...@gnome.org So, I just landed GtkListBox in Gtk+ master. Its essentially a slightly evolved version of EggListBox. One of the main differences compared to EggListBox is that it has a specific row widget GtkListBoxRow which is the only thing that can be a child of a GtkListBox (well, if you add anything else one will be inserted for you). One of the important reasons for this is that you then get a reference to the row in the css system, so that you can e.g. set the GTK_STATE_FLAG_SELECTED on it. This was a problem with EggListBox where the selected state was just temporarily set during the drawing of the row background, which meant child widgets could not match on this and thus we could not change the color of the text in a selected row to match the selection color. However, setting the state flags on the row widget exposed a weakness in the Gtk+ theming system. Gtk+ propagates most state flags (including selected, active, prelight, all used on listbox rows) to all children. This means that if a row with a button is selected, the label inside the button will look selected (white text on blue). And if you click on the row the button looks like its being activated (clicked). This is a general problem in Gtk+ for all kind of container widgets that are also interactive, and the fix (now in master) is to not propagate these states. In fact, the only states that are now propagated to child widgets are INSENSITIVE and BACKDROP. This may seem weird, as the state of a parent needs to be able to affect a child (e.g. the label color in a selected row), but it is not so strange because we use CSS to theme things, and CSS uses other ways to inherit from a parent. For instance, the color property is by itself inherited by default, so if you just set the color on the row it will automatically be applied to the label child. And if that is not enough you can match on the parent state using CSS selectors. In fact, most things just seems to work with current adwaita. However, it is possible some things are broken, so please everyone be on the lookout for things that look weird. ___ gtk-devel-list mailing list gtk-devel-l...@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Prevent sort of GtkListStore.
On Wed, Jun 12, 2013 at 11:38 PM, dE de.tec...@gmail.com wrote: With gtk_tree_view_column_set_sort_column_id (), it appears that GtkListStore also gets sorted. I don't want that to happen, since the data in it has to be compared. The sorting of GtkTreeView actually sorts the model, it does so using the GtkTreeSortable interface. If you dont want the data model to actually be modified by sorting, then you can use a GtkTreeModelSort, which is an intermediate data model for this particular purpose (just set the GtkTreeModelSort as the model for the GtkTreeView, and set your data model as the child model of the GtkTreeModelSort). Cheers, -Tristan How can I do this? Thanks!! ___ 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: Prevent sort of GtkListStore.
On 06/13/13 18:49, Tristan Van Berkom wrote: On Wed, Jun 12, 2013 at 11:38 PM, dE de.tec...@gmail.com wrote: With gtk_tree_view_column_set_sort_column_id (), it appears that GtkListStore also gets sorted. I don't want that to happen, since the data in it has to be compared. The sorting of GtkTreeView actually sorts the model, it does so using the GtkTreeSortable interface. If you dont want the data model to actually be modified by sorting, then you can use a GtkTreeModelSort, which is an intermediate data model for this particular purpose (just set the GtkTreeModelSort as the model for the GtkTreeView, and set your data model as the child model of the GtkTreeModelSort). Cheers, -Tristan How can I do this? Thanks!! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list THAT'S IT!!! YES!! THANK YOU!! ___ 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 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: # 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. -- 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
Invisible GtkImage
Hey list, I am attempting to create a GtkImage that resizes to fill its parent container while maintaining its aspect ratio. I do this by subclassing GtkImage and overriding do_size_allocate(). http://pastebin.com/SD4RBkes The code mostly works in that I can see that the area the widget is taking appears to be the correct size as I resize its parent. However, the actual image pixels do not appear to be painted. Any help appreciated, -- 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
Fwd: Setting yalign on CellRendererText
Not sure which list is more appropriate. -- Forwarded message -- From: Avi avi.w.l...@gmail.com Subject: Setting yalign on CellRendererText Date: Fri, 14 Jun 2013 01:58:17 -0005 To: gtk-l...@gnome.org I'm having issues using the yalign property on a CellRendererText. At the moment, it appears that this property is being ignored, and CellRendererText seems to always behave as if yalign = 0.5, its default value. Any tips or workarounds? ___ 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 6:09 PM, Kip Warner k...@thevertigo.com wrote: The code mostly works in that I can see that the area the widget is taking appears to be the correct size as I resize its parent. However, the actual image pixels do not appear to be painted. Hi Kip, After setting the rescaled image, you should probably Chain Up to the default size_allocate method. I'm not a python expert, but I believe Gtk.Image.do_size_allocate(self, allocation) at the end of your override should work. Looking at the implementation, the allocation needs to be stored in GtkWidget's private structure. Without chaining up, the allocation is never stored, and thus when on_draw() is called it is likely making a 0x0 sized Cairo context. ___ 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
Hi Kip, After setting the rescaled image, you should probably Chain Up to the default size_allocate method. I'm not a python expert, but I believe Gtk.Image.do_size_allocate(self, allocation) Hey Andrew. You are right. I had no idea that that had to be done, but based on my knowledge of other windowing toolkits and the underlying native implementation, what you suggest makes sense. at the end of your override should work. Looking at the implementation, the allocation needs to be stored in GtkWidget's private structure. Without chaining up, the allocation is never stored, and thus when on_draw() is called it is likely making a 0x0 sized Cairo context. That makes sense, but should the allocation passed to the base class's do_size_allocate() be the original allocation parameter that was passed into the override, or the one that I modified to contain the new image dimensions adjusted to maintain the aspect ratio? If I use the allocation passed into the override, the pixels in the image appear to rescale appropriately, but the image as a whole does not. It grows horizontally, but the height of the widget remains fixed. Any suggestions? The image is being added to the GtkAssistant page as such... page._bannerImage = BannerImage() #Gtk.Image() page.pack_start(page._bannerImage, False, False, 0) page.reorder_child(page._bannerImage, 0) Thanks for your help. -- 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 8:42 PM, Kip Warner k...@thevertigo.com wrote: That makes sense, but should the allocation passed to the base class's do_size_allocate() be the original allocation parameter that was passed into the override, or the one that I modified to contain the new image dimensions adjusted to maintain the aspect ratio? If I use the allocation passed into the override, the pixels in the image appear to rescale appropriately, but the image as a whole does not. It grows horizontally, but the height of the widget remains fixed. Yes, you should pass in the same allocation you received. A really proper way to do this would be to scale the image to less than the full allocation depending on the margins/padding/border etc., and then the base class could do the right job with honoring that stuff after you set the pixbuf. But by default that stuff is 0 and you don't have to worry about it in this case. What you can't do is allocate additional height to yourself in do_size_allocate(). So if you have a short wide image and are allocated more width than the height at your aspect ratio allows, you _shouldn't_ scale up or else your image will be clipped; the toolkit knows what it allocated to you and will not let you draw outside of that region. 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. I'm not sure on how to set the widget to do height for width allocation, it seems you may have to override get_request_mode()? What I did was override all the size request methods instead. ___ 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, 2013-06-13 at 21:32 -0700, Andrew Potter wrote: What you can't do is allocate additional height to yourself in do_size_allocate(). So if you have a short wide image and are allocated more width than the height at your aspect ratio allows, you _shouldn't_ scale up or else your image will be clipped; the toolkit knows what it allocated to you and will not let you draw outside of that region. Ok, fair enough. 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. I'm not sure on how to set the widget to do height for width allocation, it seems you may have to override get_request_mode()? What I did was override all the size request methods instead. Here's what I did... 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... ERROR:../../gi/pygi-closure.c:494:_pygi_closure_set_out_arguments: code should not be reached One thing is clear. The latter do_get_request_mode() is in fact being queried. -- 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
