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
New GObject Introspection tutorial
Hello! I've written a tutorial on how to make a basic multilevel Hello World using GObject Introspection: http://helgo.net/simon/introspection-tutorial/ It's written in Mallard; the markup is in a git repository at https://www.gitorious.org/gobject-introspection-tutorial There's a fine tutorial on this subject at the Gnome Live wiki, but there were a few things I thought should be different. It uses Clutter, which I think gets in the way if you're not already familiar with that library; I couldn't get it to build since my system has Clutter 1.0 and the tutorial uses 0.8. I also think it's preferable to show the build steps such as g-ir-scanner instead of using a build tool (waf) not all readers will be familiar with, and to not rely so much on git. So I wrote this as a way of learning for myself. I was also influenced by a blog post by Miguel de Icaza to add some exercises. :-) Would love to get all kinds of feedback, on both content and style. I have some ideas for future expansion, should really cover annotations e.g. And I need to figure out how to get yelp-build to use a Gnome standard style sheet that looks nicer on the web. Regards, Simon Kågedal Reimer ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
On 13/06/2013 00:06, Garrett Serack wrote: Awesome! I'll pop into your #hexchat-devel IRC channel tomorrow if you want to chat about it, or need some help getting started with our tools (we're still a bit behind on docs) Hi Garrett and Arnav, I'm the lead Windows developer for Harrison's Mixbus DAW:- http://www.harrisonconsoles.com/mixbus/website/ I'm based in the UK so I'm typically about 6 hours ahead of the rest of my team who are mostly US based. If I get a chance I'll join you on hexchat-devel but the earliest I could manage it would be around mid-day (CST). Not a problem if you're already done by then but it'd be great to meet up. Mixbus is also built using MSVC although we're still running VS2005. There's no particular policy about sticking with that. It's just been very reliable and hasn't caused us any problems. Anyway, hopefully see you both later. John Emmas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Hi Garrett, I maintain a GCC/MinGW build environment for GTK+ these days ; but I'm interested as well, so I might join the channel if nobody minds. Regards, Tarnyko Garrett Serack writes: Awesome! I’ll pop into your #hexchat-devel IRC channel tomorrow if you want to chat about it, or need some help getting started with our tools (we’re still a bit behind on docs) Hmm. Now that I think about it, I added a bunch of cmdlets that I never even mentioned in the docs at all (things for generating template build/packaging scripts) G From: Arnavion [mailto:arnav...@gmail.com] Sent: Wednesday, June 12, 2013 2:12 PM To: Garrett Serack Cc: gtk-devel-list Subject: Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x Awesome! I'll look into integrating this into our build script somehow. -Arnav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Attention: State propagation changed in master, themes may need changes
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-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Sure, the more the merrier! In the longer term, I *really* want to make sure we can support GCC as well. G -Original Message- From: tarn...@tarnyko.net [mailto:tarn...@tarnyko.net] Sent: Thursday, June 13, 2013 1:45 AM To: Garrett Serack Cc: Arnavion; gtk-devel-list Subject: Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x Hi Garrett, I maintain a GCC/MinGW build environment for GTK+ these days ; but I'm interested as well, so I might join the channel if nobody minds. Regards, Tarnyko Garrett Serack writes: Awesome! I’ll pop into your #hexchat-devel IRC channel tomorrow if you want to chat about it, or need some help getting started with our tools (we’re still a bit behind on docs) Hmm. Now that I think about it, I added a bunch of cmdlets that I never even mentioned in the docs at all (things for generating template build/packaging scripts) G From: Arnavion [mailto:arnav...@gmail.com] Sent: Wednesday, June 12, 2013 2:12 PM To: Garrett Serack Cc: gtk-devel-list Subject: Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x Awesome! I'll look into integrating this into our build script somehow. -Arnav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pango Hindi Text rendering error
On 13-06-12 10:01 PM, Mayank Jha wrote: you mean to say that these fonts aren't supposed to render conjugate characters ? Unless the fonts render correctly on *some* environment, I'd say the font is just incomplete. -- behdad http://behdad.org/ ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-i18n-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-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Setting yalign on CellRendererText
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-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
[gtk-osx-users] when to call gtkosx_application_ready() in an application that initializes in an idle callback
Hi all, we're currently working to fix some issues with Bluefish on OSX. Bluefish initializes the GUI in an idle callback. So gtk_main() is called very early (before there is a window created). I have a question when to call gtkosx_application_ready(). If I call it when the first window is ready, everything works fine except for one issue: if the application is started from the finder (using 'open with'), the NSApplicationOpenFile signal is not called for that filename. Once the application is running, the NSApplicationOpenFile signal works fine. However, if I call it before gtk_main() as stated in the documentation, I get two 'apple' icons in the top menu bar on the left, and the NSApplicationOpenFile signal is working as expected. How should I handle this? Olivier ___ Gtk-osx-users-list mailing list Gtk-osx-users-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list