g_app_info_remove_supports_type() needs better API documentation
Hey list, I am currently re-factoring a patch I submitted to meet the requirements of a separate upstream project (Thunderbird): https://bugzilla.mozilla.org/show_bug.cgi?id=824909 During my work in solving the aforementioned, I needed a function in GLib's GIO module to do something it was already capable of doing, but wasn't obvious from its API documentation. https://bugzilla.gnome.org/show_bug.cgi?id=729892 I've submitted the above bug report and included a patch I wrote that appears to solve this. Please consider reviewing and committing at your leisure. Respectfully, -- Kip Warner -- Senior 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: g_app_info_remove_supports_type() needs better API documentation
On Fri, 2014-05-09 at 22:57 +0100, Emmanuele Bassi wrote: hi Kip; if you need a review for a patch against GIO you should ask on gtk-devel-l...@gnome.org or (better) on IRC: the #gtk+ channel on irc.gnome.org is where the GLib and GTK+ developers hang out and communicate. Thanks Emmanuele. I'll try the other mailing list. Take care, -- Kip Warner -- Senior 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
xgettext not extracting strings in a Glade GtkListStore
Hey list, I'm not sure if this is a bug in xgettext or not, but I figured I'd run it by this list before possibly posting on bug-gett...@gnu.org. I have a sample GtkListStore declared within a Glade file containing a single row with one column of type gchararray. Note that the string is marked as translatable=yes. When I pass it through xgettext, it does not appear to see the localizable string in the GtkListStore. $ cat minimal.glade ?xml version=1.0 encoding=UTF-8? interface !-- interface-requires gtk+ 3.0 -- object class=GtkListStore id=liststore1 columns !-- column-name column_name -- column type=gchararray/ /columns data row col id=0 translatable=yesstuff/col /row /data /object object class=GtkWindow id=window1 property name=can_focusFalse/property child object class=GtkComboBox id=combobox1 property name=visibleTrue/property property name=can_focusFalse/property property name=modelliststore1/property /object /child /object /interface I am using xgettext as follows, without any foo.pot being generated against the above minimal: $ xgettext --language Glade minimal.glade --output=foo.pot -- 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: xgettext not extracting strings in a Glade GtkListStore
On Wed, 2013-08-07 at 00:08 -0700, Kip Warner wrote: Hey list, I'm not sure if this is a bug in xgettext or not, but I figured I'd run it by this list before possibly posting on bug-gett...@gnu.org. I have a sample GtkListStore declared within a Glade file containing a single row with one column of type gchararray. Note that the string is marked as translatable=yes. When I pass it through xgettext, it does not appear to see the localizable string in the GtkListStore. $ cat minimal.glade ?xml version=1.0 encoding=UTF-8? interface !-- interface-requires gtk+ 3.0 -- object class=GtkListStore id=liststore1 columns !-- column-name column_name -- column type=gchararray/ /columns data row col id=0 translatable=yesstuff/col /row /data /object object class=GtkWindow id=window1 property name=can_focusFalse/property child object class=GtkComboBox id=combobox1 property name=visibleTrue/property property name=can_focusFalse/property property name=modelliststore1/property /object /child /object /interface I am using xgettext as follows, without any foo.pot being generated against the above minimal: $ xgettext --language Glade minimal.glade --output=foo.pot In case anyone else is having this problem, this was fixed in xgettext 0.18.3 with support for Glade 3.[1] [1] https://savannah.gnu.org/forum/forum.php?forum_id=7641 -- 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
Unexpected background colour
Hey list, I have a scrolledwindow / viewport in a gray GtkAssistant that is painting a white background on Gtk 3.4.2-6 (Debian Wheezy). However, the same application is not painting white on Gtk 3.6.4-0ubuntu8 (Ubuntu Raring). I prefer the latter behaviour and would like to stop the whiteness so the region blends with the rest of the user's theme. -- 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, 2013-06-27 at 16:01 -0700, Andrew Potter wrote: Please show the code that deals with the TextView and ScrolledWindow. The clipping is almost certainly due to setting the minimum size on either the TextView, or the GtkBox the two are contained in. I have example GtkAssistant code at the bottom of this email that does not exhibit this issue until extraordinarily small window sizes. Hey Andrew. The code I posted on pastebin was the only GUI related code for that stuff. The TextView and ScrolledWindow were all created via GtkBuilder / Glade, so there isn't really anything to show, save the XML unless you want that too. That's the bad news. The good news is by changing the minimum height returned in the following override for your Gtk.Drawing subclass to 1, the clipping issue seems solved - well, almost. def do_get_preferred_height_for_width(self, width): preferredHeight = width / self.get_aspect_ratio() return (1, preferredHeight) When scaling an image, both its height and width are changing. In order to fit the allocated rectangle without clipping, one must figure out which dimension is smallest (normalized to the aspect ratio). For example, if a 200x100 image is allocated 200x50, the allocation is height-limited and the image must be scaled to 100x50. OTOH if allocated 100x100, the image is width-limited and must be scaled to 100x50. Right. Makes sense. Thank you for that clarification. I'm getting motivated to work on a patch to GtkImage to add scaling support... I think that given how much work it took for us to figure out how to get it working, probably a lot of other people might benefit from your patch, so I applaud your efforts. - Below is an example program with ScalableImage in a GtkAssistant. Example 1, start up: http://i.imgur.com/ZdqwUZG.jpg Example 2, Resized to less height. Notice the TextView/ScrolledWindow had plenty of space to give up because it has no minimum height http://i.imgur.com/wTN5rY9.jpg Example 3, Clipping occurs at this very small size due to minimum size on the ScalableImage as well as the ScrolledWindow/TextView http://i.imgur.com/EAzFYOG.jpg Yup. That's what I had observed. Example 4, ScalableImage is modified to return a 0 minimum size in get_preferred_height_for_width(). This means that at very small heights the image will not have enough space to fill the allocated width, allowing the other widgets get some space in this corner case. http://i.imgur.com/ZrOPt75.jpg It is your choice whether or not to allow your header image to become smaller when the window is pressured for height. Ok, for the sake of my application, setting it to zero / one vs leaving it at the preferred height seems to solve the clipping issue, but creates a new problem. On subsequent assistant pages, the image starts off too small and is not using the full width available. However on the first page, it fits the full width. Resizing the assistant makes it fill the full width, but only after a certain amount is met. -- 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 Mon, 2013-06-24 at 13:56 -0700, Andrew Potter wrote: Actually, it occurs to me that Kip is almost certainly going to want to change the size request methods to: def do_get_preferred_width(self): pw = self.pb.get_width() return (0, pw) def do_get_preferred_height(self): ph = self.pb.get_height() return (0, ph) def do_get_preferred_height_for_width(self, width): ph = width / self.get_aspect_ratio() return (ph, ph) Otherwise it won't scale down properly. Hey Andrew, So two questions now I have for you, if you don't mind. The first is a problem with clipping, the same one I experienced a few days ago. Note the assistant button widgets at the bottom of the assistant. Before resizing horizontally: http://en.zimagez.com/zimage/screenshot-13-06-14-051249pm.php After resizing horizontally, buttons clipped: http://en.zimagez.com/zimage/screenshot-13-06-14-051057pm.php Implementation: http://pastebin.com/ynsQFTzU The second is just a request for clarification on the min() calculation in your do_draw() override. I'd just like to better understand what that calculation is attempting to do. I also wanted to say thank you for having bared with me on this one. It's amazing how sometimes what looks like a really simple problem turns out to require a dozen minds and weeks of posts to really get to the bottom of it and realize that sometimes these things are trickier than they seem. Hopefully now if anyone else in the future wants to do something similar with an image in Gtk+, they'll manage to find this thread. Actually, it might even be worth adding on the FAQ. Another thing I'd like to thank you for is how much cleaner this implementation is than the mess I had before. It's much simpler and doesn't require the client of ScalableImage to have to know or do as much. Take care, -- 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 Sun, 2013-06-23 at 21:17 +0200, z...@excite.it wrote: Hi, maybe adding a callback to a window signal and redraw the image could be an option? take a look at http://zetcode.com/tutorials/gtktutorial/gtkevents/ gtk_widget_add_events(GTK_WIDGET(window), GDK_CONFIGURE); The event mask of the widget determines, what kind of event will a particular widget receive. Some event are preconfigured, other events have to be added to the event mask. The gtk_widget_add_events() adds a GDK_CONFIGURE event type to the mask. The GDK_CONFIGURE event type accounts for all size, position and stack order events. g_signal_connect(G_OBJECT(window), configure-event, G_CALLBACK(your_callback), NULL); Just an idea. Ciao, ZZ Hey ZZ, It's a good idea, but it's tough to implement because if you are talking about resizing a GtkImage widget dynamically, I don't think it's really designed to do that. I think some of its internal data functions on the assumption that it won't resize. I think the GtkDrawingArea widget can be dynamically resized and, as long as the client takes responsibility for resizing whatever pixels that are to be painted on it, it should work. The trick at this point is to try and get the AspectFrame and DrawingArea to resize and expand in the right way which seems very difficult so far. -- 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 Sun, 2013-06-23 at 11:51 +0200, David Nečas wrote: So how exactly does the behaviour of my simple example differ from what you want? The widget fills the allocated space and the image scales, keeping the aspect ratio. When the parent window is resized, I'd like the image to scale to fill the allocated space as much as possible, maintaining the aspect ratio. My code draws the image correctly, but it doesn't resize as the parent window is resized: http://pastebin.com/6LEzFk8A -- 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 Sun, 2013-06-23 at 00:53 +0200, Colomban Wendling wrote: 2) you say it doesn't expand: check your packing flags. You have: page.pack_start(page._bannerAspectFrame, False, False, 0) the 2 False mean don't expand and don't fill the available space. Change this to True, True and you'll be happy. Hey Colomban. I actually already tried that. If I set the second parameter to True, it does expand to fill the available space, but the other widgets below it in the next row below in the vbox are pushed down to the bottom half of the box's available space so that there is a huge wasted space between the banner image and the bottom half. -- 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 Sun, 2013-06-23 at 20:11 +0200, David Nečas wrote: Well, as it has already been suggested, this is a matter of packing. If you request that the widget does not expand page.pack_start(page._bannerAspectFrame, False, False, 0) then the containing box will not expand the widget when it is enlarged itself. You have to pass expand=True, fill=True. Hey David. Like I said to Colomban already, I already tried that. https://mail.gnome.org/archives/gtk-app-devel-list/2013-June/msg00134.html -- 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
For a vertically orientated GtkBox, the 'expand' field in pack_start is going to be vertical expansion, so you are not going to want that. Instead set the GtkBox.set_hexpand(true) (and GtkBox.set_halign(GTK_ALIGN_FILL)), but definitely do pack children with Fill=True. Make sure both the GtkAspectFrame and the GtkDrawingArea are set to both set_halign(GTK_ALIGN_FILL) and set_valign(GTK_ALIGN_FILL). That means the aspect frame will receive the extra width, and its internal ratio keeping will make its implementation of get_requested_height_for_width() request enough height for your image to expand properly. Its all a problem of packing with expand fill at this point. Just think about how you want the toolkit to work and make sure each component in the hierarchy is doing the right thing. Hey Andrew. Thanks for the help. I've almost got it working after I took your advise, but the image is still taking up too much room in the vertical GtkBox above and below it. See all the extra space above and below it I'd like collapsed: http://en.zimagez.com/zimage/box36.php Here is my code: http://pastebin.com/mtVNsPrb Thanks a lot, -- 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 Sat, 2013-06-22 at 11:33 +0300, אנטולי קרסנר wrote: The code looks fine. I think the problem is that scaling images are rarely used in GUI. Usually, they scale to fixed sizes and not directly depend on a container scaling to arbitrary size. This is probably why getting the result you want is not easy. Hey Tom. Yes, definitely the resizing is the difficulty. It's amazing how much time I've spent on just trying to get the image to resize. Try the canvas idea. You can probably use any simple drawing area widget (I never used one personally) from Gtk or Cairo. This is what I've come up with so far. The image paints on the DrawingArea properly, but it doesn't resize at all when I resize the parent window. http://pastebin.com/Mj7bTJLh -- 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 Sat, 2013-06-22 at 19:18 +0300, אנטולי קרסנר wrote: I never used drawing areas, but here are my suggestions. First, does the drawing area resize? If it does, all you need to do is to change the code which draws the image to use the drawing area's dimensions, and scale the image accordingly (I don't know how to do that, but I'm sure Cairo can help. In the worst case, from personal experience I know OpenGL can do that, if you have no choice...). That was my first line of inquiry, except it doesn't seem to resize. I can see this because if I leave a frame border on the parent AspectFrame, it doesn't resize. If the drawing area doesn't resize, try to put it in a GtkGrid. I tried putting the DrawingArea into a 1x1 Grid, in turn inside of an AspectFrame, but it still doesn't resize. If it doesn't help - maybe you can removing the aspect frame and calculating the image dimensions manually. Even if I remove the aspect frame and calculate the image dimensions myself, there still seems to be no way I can find to reliably resize it dynamically. I can't believe resizing a widget in Gtk+ is this difficult. I think I've tried everything by now. Viewports, AspectFrame, cairo, Gdk pixbuf, subclassing and overrides. You'd think something like this would be really straightforward. =( -- 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 Sun, 2013-06-23 at 00:08 +0200, David Nečas wrote:
Frankly, I don't quite understand what you are trying to achieve since
you have never posted anything runnable and your examples have never
included any actual drawing code.
Hey David. I had posted my cairo drawing code a couple posts ago, but
this thread is getting long and you may have missed it:
http://pastebin.com/Mj7bTJLh
Before that, I had posted several times code using GtkImage as well. In
any case, they didn't work properly, it doesn't matter now, and I'm
grateful for your help.
Anyway, it is trivial to create a
scaleable widget (whether it draws an image or anything else):
---
from gi.repository import Gtk, GdkPixbuf, Gdk
class ScalableImage(Gtk.DrawingArea):
def __init__(self, filename):
super(ScalableImage, self).__init__()
self.pb = GdkPixbuf.Pixbuf.new_from_file(filename)
def do_get_preferred_width(self):
pw = self.pb.get_width()
return (pw, pw)
def do_get_preferred_height(self):
ph = self.pb.get_height()
return (ph, ph)
def do_draw(self, cr):
alloc = self.get_allocation()
pw, ph = self.pb.get_width(), self.pb.get_height()
aw, ah = float(alloc.width), float(alloc.height)
r = min(aw/pw, ah/ph)
cr.scale(r, r)
Gdk.cairo_set_source_pixbuf(cr, self.pb, 0.0, 0.0)
cr.paint()
return False
w = Gtk.Window(Gtk.WindowType.TOPLEVEL)
w.connect('destroy', Gtk.main_quit)
b = Gtk.Box(orientation=Gtk.Orientation.VERTICAL)
w.add(b)
b.pack_start(Gtk.Label(label='Test'), False, False, 0)
d = ScalableImage('/usr/share/icons/HighContrast/48x48/stock/gtk-ok.png')
b.pack_start(d, True, True, 0)
b.pack_start(Gtk.Label(label='Somewhat longer test'), False, False, 0)
w.show_all()
Gtk.main()
---
This might not be exactly what you need but as I noted I don't get where
the problem is...
Yes, your code is similar to what I had tried before with GtkImage,
only you're subclassing the DrawingArea instead which is probably a
better idea, except it still doesn't work properly either. My code
draws the image correctly, but it doesn't resize as the parent window is
resized...
http://pastebin.com/6LEzFk8A
If you need your widget to be a GtkImage subclass things will likely
turn hairy because GtkImage is not scaleable, all its methods think it
is not scaleable so you will end up fighting the implementation of the
widget.
Yup.
--
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, 2013-06-21 at 11:46 +0300, אנטולי קרסנר wrote: Hey Kip, Hey Tom. You can try to place your image into a 1x1 GtkGrid and see if it works. If not... hmmm... I'm trying to think of an existing Gnome app which has scaling images. Hmmm... probably none. Scaling images (unless in Gimp/Inkspace) to containing widget size is probably rarely done. Ok, I tried it with GtkGrid containing the image widget with the parent of the former being the AspectFrame. No love. It behaves the same as without it. Anyway, here's another idea: You can try to solve the recursive scaling problem by not using all the available space. Try to make the image fit, say 90% of the aspect frame. Then the image is not big enough to cause the aspect frame to rescale (which probably would cause the recursive scaling). You may get a little bit of screen space wasted, but if you don't mind the 10% (maybe you can reduce it to 5% or less) it's okay. I think that's a good idea, but I'll try that as a last resort. So I've almost got it working. It resizes properly when I make the window larger, but the window's width can never be made smaller (including after maximization). http://pastebin.com/q76RJ4UH Can you see anything broken in that? Another idea: Image editing software usually uses a custom canvas and draws things on it, including scaled SVG images. Maybe you can put such a canvas in the aspect frame, possible also inside a 1x1 GtkGrid, and scale the image within the canvas. Then, the image scaling is just a canvas drawing operation and has no effect on the AspectFrame size, and shouldn't cause recursive scaling. I don't know much about the canvas. But I'll try it and get back to you. Thank you 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 Wed, 2013-06-19 at 14:03 +0300, אנטולי קרסנר wrote: I have another idea for you: In the Gnome Mines game (which you can probably find on git.gnome.org) written in Vala, the game board has a fixed ratio and resizes with the window, exactly like your requirement. Go there and see how the MinefieldView and Window classes word. Hey Tom. So I'm looking through his gnome-mines.vala and I see in his startup_custom_game_screen () function he is creating the GtkAspectFrame as I do. I think the key difference is the child he is using is a GtkGrid which already knows on how to resize inside of anything, whereas the GtkImage does not. I'll keep looking through his code and fiddling with my own, but 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
Re: Invisible GtkImage
On Thu, 2013-06-20 at 17:59 -0700, Kip Warner wrote: On Wed, 2013-06-19 at 14:03 +0300, אנטולי קרסנר wrote: I have another idea for you: In the Gnome Mines game (which you can probably find on git.gnome.org) written in Vala, the game board has a fixed ratio and resizes with the window, exactly like your requirement. Go there and see how the MinefieldView and Window classes word. Hey Tom. So I'm looking through his gnome-mines.vala and I see in his startup_custom_game_screen () function he is creating the GtkAspectFrame as I do. I think the key difference is the child he is using is a GtkGrid which already knows on how to resize inside of anything, whereas the GtkImage does not. I'll keep looking through his code and fiddling with my own, but any help appreciated. Ah hah. So I noticed something. When I set the shadow type to NONE in the AspectFrame, the recursive resizing stops. I can make the window larger, but not smaller. Hmm... -- 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 Tue, 2013-06-18 at 10:33 +0300, אנטולי קרסנר wrote: Hmmm... did you try not to resize the image at all, and see if it gets resized automatically by the aspect frame? If the ratio of the image isn't identical to the aspect frame ratio, I guess it may result in each one of them resizing the other recursively. Try without the resize code, and see if it works. If not, maybe use some layout/alignment properties to make the image adapt, rather than manually setting the new size. Maybe this will work. I Hope it helps :-) Hey Tom. Thanks for the help. If I comment out the draw signal connection on line 34, the aspect ratio doesn't resize at all, but just stays fixed, albeit at the correct aspect ratio. http://pastebin.com/jFCcWyig Ugh, *slams head on desk* -- 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 Mon, 2013-06-17 at 22:05 +0300, אנטולי קרסנר wrote: Just to make sure you checked the small things... Did you try AspectFrame? IIRC that's exactly what it does: keeps the ratio of the contained widget. IIRC, the Gnome Mines game (aka minesweeper) uses this kind of container to keep the minefield view square-shaped even when the window is stretched to different directions. It fills the space, but without losing the ratio. Hey Tom. Great idea. I definitely overlooked the small and obvious thing this time. I totally forgot about the GtkAspectFrame. It makes a lot more sense to use that in this case than going to all this trouble subclassing GtkImage, overriding virtual methods, etc. So this is what I came up with... http://pastebin.com/jFCcWyig It works great, except for one thing. The GUI doesn't freeze thankfully, but the image or aspect frame just keeps _growing_ and doesn't stop. I'm guessing what's happening in the draw signal callback is I am resizing the image widget, which in turn is resizing the AspectFrame widget, which is in turn resizing the image widget, etc... -- 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 Sat, 2013-06-15 at 09:54 +0100, jcup...@gmail.com wrote: I never found the Python debuggers very useful. Event-driven programs are not a great fit with traditional debuggers, in my opinion, because execution is so non-linear. You are running tiny scraps of code all over the place in an order set by an external driver that varies between runs. Totally agree. I use an interactive python interpreter to try stuff out, plus a lot of logging. For example, I did a music player that pulses a set of lightbulbs in time: Yeah, I all too often find myself having to resort to that as well with Python. https://github.com/jcupitt/huebert/blob/master/huebert/controller.py That's so cool. That's a great gadget too. -- 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 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 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, 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: 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
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, 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
Re: GUI freeze and long blocking operation
On Wed, 2013-06-12 at 09:50 +0100, jcup...@gmail.com wrote: Do you need to use idle_add()? Hey John, 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() Thanks a lot 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
GUI freeze and long blocking operation
Hey list, My GtkAssistant on one page in particular performs a long operation which would otherwise block the GUI from refreshing, if it were not for intermittent... while Gtk.events_pending(): Gtk.main_iteration() The application is single threaded and performs all operations from the main loop. I had originally broken this into a separate worker thread, but Python threads, the VM, GObject / GLib, and Gtk+ do not always seem to play well with each other when using threads. To start the long work, the prepare signal is captured in my assistant and the long job (startDiscVerification()) method is enqueued via GObject.idle_add() in the onPrepare() method. As mentioned previously, intermittently the function updates the GUI via the above technique. http://pastebin.com/fcTDrsu9 This all works fine, however, when the long job completes, the entire UI hard locks and does not appear to be responsive. It's almost as though the main loop totally dies or something. Trying to look for a stack trace, if I'm using pdb correctly, it looks like it's left hanging on this: /usr/lib/python3/dist-packages/gi/overrides/GLib.py(629)lambda()-False - return (lambda data: callback(*data), user_data) I've heard some mention that you should not pump the message queue (e.g. Gtk.main_iteration()) from within an idle callback. However, if I don't do this, the GUI is frozen during the long job. If I call the long job (startDiscVerification()) from within the prepare signal callback immediately, as opposed to en-queueing via GObject.idle_add(), then the GUI doesn't refresh throughout the duration of the long job, even though I pump the message queue. 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
GtkAssistant page visible
Hey list, Is there a signal I should be listening for that is emitted when a page on my GtkAssistant is visible for the first time? By visible, I mean has already been constructed (e.g prepare signal) and is now visible. Each page in my GtkAssistant is a GtkBox containing child widgets. -- 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: Image resizing
On Sun, 2013-06-09 at 00:12 -0700, Andrew Potter wrote: One approach is ditching the ScrolledWindow and overriding the get_preferred_width_for_height/width() vfuncs to return the full image width, and then in size_allocate() set the image to a scaled pixbuf of the allocated width. This involves making a subclass which is a little bit of work if you've never done it before (especially in straight C). The only example I have on hand [1] is in Gtkmm and does quite a bit more than you need (Animated image support, toggling between thumbnail and full size). But overriding these functions should be enough: size_allocate() get_preferred_height() get_preferred_width_for_height() get_preferred_width() get_preferred_height_for_width() [1] https://github.com/talisein/Horizon/blob/master/src/horizon_image.cpp Hey Andrew, Sadly I haven't really much experience with Gtk+ in C or Gtkmm with C++. I think it might be easier at this point if I just fixed the Python code I've written thus far rather than refactoring it with custom overrides. The code mostly works, it's just the scrollbar issue that's really annoying. Any help really 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
Image resizing
Hey list, I'm still having issues with my Gtk+ code. I have a GtkAssistant with a bunch of pages (GtkBoxes) with various child widgets in them defined through Glade. At runtime, a banner image is inserted into the top of each page as the first child widget. This is done by placing the banner image into a viewport, in turn inserted into a scrollable window, in turn inserted into the parent page. http://pastebin.com/Xbgur3pp The banner image should automatically resize as the window is resized. It should use the full width available in the parent page (GtkBox), but the image's height should be calculated as a function of the aspect ratio to keep it from being distorted. This works fine, but sometimes the scrollbars appear in the scrollable window (or viewport?) and a small edge of the bottom or right of the image is clipped unless the user scrolls. Setting the scroll policy to NEVER means the image resizes properly when the window is made larger, but can never shrink after that. These scrollbars appear if the window is maximized, or sometimes when not under certain Gtk+ themes. I don't want the scrollbars to ever appear and the full image to always be visible. Any help appreciated. Respectfully, -- 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: VTE questions
On Wed, 2013-06-05 at 21:49 +0800, Arnel A. Borja wrote: Sorry, quite busy these last few days. For the auto-scrolling, I think that's the expected behavior, is it not? VTE has an option to enable/disable automatic scrolling, try checking that one. Yes, I meant I'm fine with automatic scrolling. The problem was that it stopped when I maximized the window, up until I manually dragged the thumb down to the bottom again. For the sunken border, I also can't find a fix for that, it also doesn't work here. Maybe you could ask on VTE's mailing list. Good idea. I forgot there was one. -- 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: VTE questions
On Wed, 2013-06-05 at 21:49 +0800, Arnel A. Borja wrote: Maybe you could ask on VTE's mailing list. I can't seem to find it anymore, or maybe I had it confused with this list. I don't see a VTE list here, https://mail.gnome.org/mailman/listinfo/ , and I've looked around. According to its README, it doesn't have its own website either. -- 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: g_callable_info_get_n_args assertion fail - core dump
On Thu, 2013-05-16 at 19:04 -0700, Kip Warner wrote:
Hey list,
I'm getting this very rare and unpredictable error which is difficult to
replicate. I have a secondary Python worker thread which very rarely
creates the following error:
** (Main.py:32524): CRITICAL **: g_callable_info_get_n_args:
assertion `GI_IS_CALLABLE_INFO (info)' failed
**
ERROR:girepository/gicallableinfo.c:150:g_callable_info_is_method:
code should not be reached
Aborted (core dumped) /usr/bin/env python3
${PythonLauncherMain} ${Arguments[@]}
With something like that, I'm totally stumped on where to begin
debugging. But one thing is clear, I do call the following before doing
anything with threads...
GObject.threads_init()
Gdk.threads_init()
Any help appreciated =)
Hey list,
I'm still having this issue and I haven't been able to pinpoint what's
causing it. It's very irregular and only shows up very rarely.
I've filed a bug report upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=701692
--
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: Widget alignment
On Thu, 2013-05-30 at 20:45 -0700, Kip Warner wrote: On Mon, 2013-05-27 at 01:01 -0700, Kip Warner wrote: Ok, I think I've got it. I put all the widgets and boxes in a page into a single vertical oriented GtkBox with its contents vertically centred and the box set to expand. Then I insert the banner widget into the parent box. It seems to work. It seems as though I may have spoke too soon. The image widget is placed correctly and the image inside of it automatically rescales to fit the maximum space that it can. However, when maximized, the scrollbars on the GtkScrolledWindow, parent widget to the GtkImage widget, become visible which I do not want. Perhaps I am using the wrong parent widgets, or they are just configured wrong. http://pastebin.com/ywRtGGY3 Suggestions welcome. Hey John. I wonder if you have any suggestions? -- 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: VTE questions
On Wed, 2013-05-29 at 22:41 -0700, Kip Warner wrote: On Wed, 2013-05-29 at 18:58 +0800, Arnel A. Borja wrote: Remove GtkScrolledWindow (right-click the recoveryTerminal in the right sidebar then select Remove Parent in the popup menu) then add a GtkScrollbar to box31. Make sure that the terminal is set to expand horizontally, and the terminal and the scrollbar has the same (vertical) adjustment. Something else I noticed. The scrollbar automatically scrolls down as the VTE widget's output fills up, as I expected it to. However, when I maximize the window, the VTE stops automatically scrolling unless I manually drag the scroll thumb down to the bottom. Hey Arnel. I'm still having this issue and if you could spare a minute, it would be really appreciated. I'm also still not seeing the sunken border either. I tried setting the frame's border to etched in, but still no luck. -- 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: Widget alignment
On Mon, 2013-05-27 at 01:01 -0700, Kip Warner wrote: Ok, I think I've got it. I put all the widgets and boxes in a page into a single vertical oriented GtkBox with its contents vertically centred and the box set to expand. Then I insert the banner widget into the parent box. It seems to work. It seems as though I may have spoke too soon. The image widget is placed correctly and the image inside of it automatically rescales to fit the maximum space that it can. However, when maximized, the scrollbars on the GtkScrolledWindow, parent widget to the GtkImage widget, become visible which I do not want. Perhaps I am using the wrong parent widgets, or they are just configured wrong. http://pastebin.com/ywRtGGY3 Suggestions welcome. -- 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: VTE questions
On Wed, 2013-05-29 at 18:58 +0800, Arnel A. Borja wrote: Remove GtkScrolledWindow (right-click the recoveryTerminal in the right sidebar then select Remove Parent in the popup menu) then add a GtkScrollbar to box31. Make sure that the terminal is set to expand horizontally, and the terminal and the scrollbar has the same (vertical) adjustment. Something else I noticed. The scrollbar automatically scrolls down as the VTE widget's output fills up, as I expected it to. However, when I maximize the window, the VTE stops automatically scrolling unless I manually drag the scroll thumb down to the bottom. -- 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: VTE questions
On Wed, 2013-05-29 at 06:59 +0800, Arnel A. Borja wrote: Try copying Anjuta's way of packing a terminal; it uses a GtkFrame to pack a horizontal GtkBox which contains the VteTerminal and the GtkScrollbar. Hey Arnel. Thanks for your help. I did what you suggested, but perhaps the properties on the parent container of the VTE widget need tweaking because the top of the terminal is still clipped: http://en.zimagez.com/zimage/screenshot-13-05-28-102127pm0.php -- 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
VTE questions
Hey list, I have a VTE widget. In order for it to be scrollable, should it be nested within a GtkViewport or a GtkScrolledWindow? I couldn't tell from its documentation. Secondly, how do I add a sunken border to the VTE widget? I tried adding a GtkFrame as its parent with different styles, but none of them appear to be sunken. Thank you, -- 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: Widget alignment
On Thu, 2013-05-23 at 11:13 +0100, jcup...@gmail.com wrote: On 23 May 2013 01:18, Kip Warner k...@thevertigo.com wrote: http://pastebin.com/821dmjKq I think your scrolled window is being allocated the width of the page, and then the image is falling to the left within that. Try without the srcolled window. Could you post a complete example? Ok, I think I've got it. I put all the widgets and boxes in a page into a single vertical oriented GtkBox with its contents vertically centred and the box set to expand. Then I insert the banner widget into the parent box. It seems to work. -- 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: Widget alignment
On Wed, 2013-05-22 at 12:32 +0100, jcup...@gmail.com wrote: Hi Kip, Hey John, GtkImage is a subclass of GtkMisc, and misc does alignment: https://developer.gnome.org/gtk3/stable/GtkMisc.html#gtk-misc-set-alignment Set the horizontal alignment to 0.5 to centre the image within its parent. Tried that already, both progmatically and via Glade. Still no love. =( http://pastebin.com/821dmjKq The decoratePage() method is invoked when the page is registered into the assistant via registerPage(). Thanks a lot for your help. This issue has been bugging me for a while. -- 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
Widget alignment
Hey list, I have a bunch of widgets inside of a vertical GtkBox being used as a page in a GtkAssistant. All of its widgets are grouped inside a child GtkBox within the aforementioned such that the child box floats in the vertical centre of the parent box. The parent box is the one used as a page in the GtkAssistant. When I invoke a method called decoratePage(page), a banner image is inserted into the page (the parent GtkBox) via pack_start() / reorder_child(). How can I have this image widget added to the parent such that it is always vertically aligned with the top of the page, but keeping the other child box below it still vertically centred? I've tried wrestling with Glade, but I can't figure out how to do it. 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: GtkAssistant apply signal
On Sat, 2013-05-18 at 17:47 +0900, Tristan Van Berkom wrote: Here's an idea, ... in the GtkAssistant documentation for apply[0], it says: The default behavior of the GtkAssistant is to switch to the page after the current page, unless the current page is the last one. Which means, you could do possibly two things: a.) In your derived GtkAssistant object, decide whether or not to invoke the parent class -apply() method from your own -apply() method which you override in your sublcass Hey Tristan. Thanks for both suggestions. This first one I don't know how to do because the GtkAssistant is being created by glade, and unless there's some kind of Python magic I could rely on, I don't know of an easy way to subclass it when it is already instantiated. b.) Connect to the apply signal on an assistant which you did not derive, and if the page is not valid, then just call: g_signal_stop_emission_by_name (assistant, apply); to avoid the default behaviour of switching pages. Both 'a' and 'b' would have the same effect (I have a preference for 'a' since I feel like 'b' is a sort of hack, but that's just my preference). 'b' is definitely a hack, but it might do the trick if I can get it to work. I am trying the following, assistant.stop_emission(apply) , except that the assistant still advances to the next page regardless. Hmm... -- 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: GtkAssistant apply signal
On Sat, 2013-05-18 at 10:38 +0200, Sébastien Granjoux wrote: In the project-wizard in Anjuta, I have added a dummy page after each one. I don't block the transition between the current page and this dummy one. I check if the transition is valid in the prepare handler of the dummy page. If the transition is valid, I automatically switch to the page after the dummy one. Else, I switch back to the original page. Hey Sébastien. Thanks for the suggestion. I think that's a good hack and I might give it a try if I can't get Tristan's stop_emission(apply) logic to work. -- 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
GtkAssistant apply signal
Hey list, During handling of the apply signal in my GtkAssistant, what is the recommended way of stopping the assistant from advancing to the next page if my code would like to abort the apply transitioning to the next page automatically? I am aware of the set_page_complete() function, however I don't actually know if the page is ready to transition to the next page until the apply button is actually pressed. What I'm doing now if I ever want to stop the apply signal transitioning to the next page is to run the following in the apply signal callback where currentPageIndex is the index of the assistant page containing the apply button. assistant.set_current_page(currentPageIndex - 1) This works, excepts it has an obnoxious side effect. This makes the 'previous' button transition to ghost pages however many times the above 'apply' code is run if the user clicks 'previous' on the page containing the apply button. By ghost page, I mean clicking previous goes back, but the page doesn't actually change, only on the left page list in the assistant. -- 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
g_callable_info_get_n_args assertion fail - core dump
Hey list,
I'm getting this very rare and unpredictable error which is difficult to
replicate. I have a secondary Python worker thread which very rarely
creates the following error:
** (Main.py:32524): CRITICAL **: g_callable_info_get_n_args:
assertion `GI_IS_CALLABLE_INFO (info)' failed
**
ERROR:girepository/gicallableinfo.c:150:g_callable_info_is_method: code
should not be reached
Aborted (core dumped) /usr/bin/env python3
${PythonLauncherMain} ${Arguments[@]}
With something like that, I'm totally stumped on where to begin
debugging. But one thing is clear, I do call the following before doing
anything with threads...
GObject.threads_init()
Gdk.threads_init()
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
Re: Updating GUI during long operation
On Thu, 2013-04-25 at 20:54 -0600, Michael Torrie wrote: As both Chris and Colomban have state, triggering an event flush isn't going to help. If the events are already getting filed up, trying to flush them isn't going to work. You have to figure out why the events are piling up. Because they're going to keep piling up no matter how often you try to pump the event loop. Hey Michael. The GIF animation has a high a frame delay of 50 ms which I believe is slowing the window repaint down when the system is already bogged down with a CPU and I/O intensive secondary worker thread. Flushing the message queue actually does seem to work, as the PyGtk FAQ recommended I do. Something I do for animations is have a timeout callback that updates the GtkDrawingArea with the latest buffer, rather than updating the drawing area whenever something is drawn. I'm actually not explicitly updating the animation myself. I provide a path to the animated GIF into a Gdk.PixbufAnimation, in turn fed into a GtkImage widget. Sounds like you're trying to re-invent the wheel here as well. From what you say (when you're not berating people for being unhelpful), you've implemented your own throbber widget. Perhaps you should either use a Gtk throbber, or study the throbber widget code and implement something along the same lines with your own graphic. Thanks Michael, but as with Chris' post, yours was not particularly constructive either. Take care, -- 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: Updating GUI during long operation
On Thu, 2013-04-25 at 22:18 -0700, Simon Feltman wrote: A brief look at the source and it seems there is nothing calling Gdk.threads_init which I think is needed. Hey Simon. I'm actually calling GObject.threads_init() over in Main.py. I've been told by others that this is enough, whereas others have said your call is more appropriate. I think what I'll do is just play it safe and use both as the faq suggests in the order given: https://live.gnome.org/PyGObject/IntrospectionPorting#Threads Similarly, use Gdk.threads_add_idle instead of GObject.idle_add for scheduling GUI updates from worker threads. The necessity of these is still somewhat unclear to me at the moment though. I'll give that a try. I'm not sure what the difference is either, but the link above seems to recommend it too so it can't hurt to try. Enough questions have come up recently with Python and GTK+ threading that I've added a wiki page here: https://live.gnome.org/PyGObject/Threading This is very much a work in progress and I appreciate updates or validation if you find any of this useful. Thanks a lot and I'll definitely give it a look. The threading model in Python is pretty bad and you might consider a different technique (please read up on the Python GIL if you don't already know how threading in Python works). If the operation is IO bound, look into using async IO with Gio. If it is CPU bound, take a look at the Python processing module or even numpy for certain things. These techniques will make the app much more responsive because other threads won't be blocked by the GIL. In my case, my worker thread is actually both CPU and I/O intensive as it generates md5 checksums of large files on disk. I could try with a non-blocking approach, but it might mean re-factoring a fair amount of code. A surprising example is as follows: sum(range(100)) This seems to completely block any other Python threads for the entirety of the operation. I think the reason is because the GIL is held the whole time and Python is not giving time to other threads for the duration of the call (this includes GTK+ update callbacks written in Python). I think so too. If you split the operation up, you can gain interactivity with other threads because Python will interleave statement execution with giving time to other threads (at the cost of performance). total = 0 for i in range(0, 100, 100): ... total += sum(range(i, i + 100)) Yes. That's a good observation. One should note that it's not guaranteed because the implementation could always change one day, but I understand what you are saying. In this sense Python is really always single threaded in regards to running pure Python code in which none of the statements ever release the GIL (IO related functions should be fine though). And if there are not any calls which release the GIL, Python threads might just be adding overhead and confusion. Yeah, I know what you mean. I once wrote a VM and I realized that probably most of them for most languages are ultimately single threaded. Finally, the same example using numpy will allow the same operation to run completely unblocked by the GIL in its own thread, so you keep full interactivity with actual concurrent processing of the threads (and the operation is about 10 times faster than the first example). numpy.sum(numpy.arange(100)) I'll definitely earmark numpy. It could be very useful in the future. Thanks Simon. -- 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: Updating GUI during long operation
On Fri, 2013-04-26 at 15:16 +0200, Colomban Wendling wrote:
That's weird. However, although I don't know much about Python
threading (and another guy in this thread suggests it's not really
good), I'm wondering whether your thread couldn't be simply locking
stuff used by both GUI and worker thread, effectively blocking the GUI one.
It's possible, but I'm not explicitly trying to lock any resources (e.g.
via a mutex or what have you).
For example, your idle callback _updateGUI() uses the thread's self, so
I guess Python would lock it.
Ah, I see what you mean (GIL).
And this would mean that the callback and
the thread functions could not run concurrently. And even worse, if the
Python thread model is based on simple functions locks (e.g. the lock is
held at the function entrance, and only released on function leaving),
this would mean the callback could never run before the thread as
finished. I don't know, but this is an idea from where the issue might
come from.
Yes, that's possible. But the good news is that when I took Simon's
advice and replaced the GObject.idle_add() calls with ones to
Gdk.threads_add_idle(), the GUI seems fully responsive.
BTW, in VerificationThread.run, which I believe is run in the thread,
right?, there are access to GTK widgets (self._assistant). This either
requires a lock (which may be the reason why your thread would block the
main one), or it may crash (since GTK is NOT thread safe). Anyway, I
think this should rather be done in the idle callback. BTW, you
actually mark the page as complete in both run() and _setQuitOk() which
is called by run().
Yes, you're right. Those calls were only made at the end of the thread's
execution, but they shouldn't be there anyways and should have been
moved into the idle callback. Thanks for spotting that.
I don't think optimizing the worker thread is the solution for the GUI
issue. If everything worked as it should, the worker thread could take
as much time as it wanted, and it still wouldn't block the main thread.
That's the point of threads: doing tasks in parallel. Of course
reducing the time the worker thread takes would reduce the UI freeze
duration, but it wouldn't solve it.
I agree and in a perfect world, that's what would happen. Except I
think there are peculiarities, as I am learning, in how the GIL is
implemented as well as subtle things in how animations are driven with
the Gtk Image widget. Thankfully it seems to work fine now (today, at
least) with the conversion to Gdk.threads_add_idle()
However, if most of your thread's time is lost in IO rather than
computation time (e.g. if the MD5 runs faster than the IO), you could
perhaps avoid a thread using asynchronous IO calls and computing the sum
by packets. Something like this (in Vala pseudo-code):
async string sum(File file) {
var sum = new MD5();
while (true) {
/* read by blocks of 2048 bytes (or whatever) */
var data = yield file.read_async(2048);
if (data) {
sum.push(data);
} else {
break;
}
}
return sum.hash();
}
Here yield would work like in Vala, which basically means calling a
implicit callback which will perform the following instructions when the
asynchronous work is done.
But this doesn't explain why your program blocks the main thread, and
may very well not be practical in your case (or even, on Python, I don't
know).
I thought of the asynchronous approach and it's possible, but I am lazy
and don't really want to have to re-factor a lot of code now. But
thankfully it seems to work better now anyways. But I'll definitely keep
that approach in mind in the future.
Hope this could help in some way. Regards,
Colomban
Thanks a lot Colomban. Like before, your thoughts were very constructive
and useful.
--
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: Updating GUI during long operation
On Fri, 2013-04-26 at 13:52 +0200, Nicola Fontana wrote: gdk_threads_add_idle() is only a convenient way of calling g_idle_add() without the need of decorating the callback code with a gdk_threads_enter()/gdk_threads_leave() pair: http://developer.gnome.org/gdk/stable/gdk-Threads.html#gdk-threads-add-idle-full The code of the dispatcher can be found here: http://git.gnome.org/browse/gtk+/tree/gdk/gdk.c?id=3.8.1#n779 Thanks Nicola. For some reason, and perhaps this is just coincidental, but I've noticed the GUI seems fully responsive since I exchanged GObject.idle_add() for Gdk.threads_add_idle()? I wonder why, or if that's just coincidental and my machine is just better behaved today for an unrelated reason. -- 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: Updating GUI during long operation
On Sat, 2013-04-20 at 18:54 +0200, Colomban Wendling wrote: Just never do something time consuming in the main loop thread. If you don't there should not be any lag. Hey Colomban. The time consuming task is in its own separate thread, but it's making a GIF animation lag and user interface responsiveness as well. And to communicate with the main loop from another thread, the common technique is to add an idle handler (that runs only once). The GLib main loop is thread safe so you can simply call g_idle_add() from the worker thread. Yes, that's what I am currently doing. I was using GObject.idle_add(self._updateGUI, ...) within the worker thread to specify a function to be called regularly that could provide some other GUI related update tasks, including the following within it... # Pump the Gtk+ event handler... while Gtk.events_pending(): Gtk.main_iteration() That's a bad idea. Forcing flush of pending events never is a real solution, since at most it will perform everything that was queued, but certainly not what will come. And as you see yourself, it doesn't work that well anyway. I actually don't know how well it would work, if it wasn't for the stack overflow crash as a result of the callback recursively calling itself each iteration of Gtk.main_iteration() above. However, my application will crash if I do this with a stack overflow within updateGUI. I'm assuming that since idle_add posted the message to call the updateGUI callback, when the callback is invoked and tries to pump the message pipeline, the method is invoked again because it still hasn't cleared itself from the queue. That's weird, but yeah, since main_iteration() tells the main loop to perform an iteration and you do this from an idle event I could imagine your idle event calls itself recursively. Again, just never use this workaround method of forcing main loop iterations. Ok, sounds good. I could have tried this aforementioned event pump from outside the updateGUI callback and done it from within the worker thread, but I didn't know if that was thread safe to do. I think the main loop is completely thread safe, event with this, but again *do not do this*. If the even loop freezes, it's that you do too much work in it's thread, nothing else. Check what you do in the main thread and that takes time, and try either optimizing it or movie it to another thread. I think what I'll have to do is try optimizing the thread to give the event pipeline a chance to breath, but then that still begs the question of the best way to do that. I thought of manually flushing the event queue, but I don't think you can do that from the worker thread and you mentioned it is not a good idea to do even if you could. -- 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: Updating GUI during long operation
On Thu, 2013-04-25 at 22:53 -0400, Allin Cottrell wrote:
I have a situation which might, perhaps, be akin to yours. From the
GUI, my app calls an iterative numerical procedure that can be quite
time consuming. Without any special treatment, this causes the GUI
to appear frozen and unresponsive, as if something had gone wrong.
My solution was to introduce a breather, as you call it. I
installed a callback function, to be called every k iterations of
the numerical procedure (for a suitable value of k). The callback
simply looks like this:
static void gui_show_activity (void)
{
while (gtk_events_pending()) {
gtk_main_iteration();
}
}
Hey Allin. Thanks a lot for your help. It's similar to my situation, but
unfortunately in my case the demanding work is in a secondary thread
where events_pending() / main_iteration() don't seem to do anything from
the secondary thread. I'm guessing because it's a separate event queue
in each thread and we're really not suppose to be doing GUI operations
outside the main thread anyways.
So I tried using idle_add() in the worker thread to have a callback
invoked periodically from within the main thread which in turn does
exactly what your gui_show_activity() function does, but the problem is
that the callback calls itself recursively until the stack blows up
because main_iteration() call invokes the callback again since the last
invocation was never removed off the queue yet. Almost got it. Arg.
--
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: Gdk PixbufAnimation supported formats
On Thu, 2013-04-18 at 02:08 -0700, Andrew Potter wrote: You can make a few png or jpg frames and hook up a g_timeout_add() callback to set the pixbuf on a GtkImage. I done similar when I needed to dynamically scale animated gifs. Be sure to stop your timeout on unmap()/unrealize(), especially if you have more than a handful of animated images instantiated anywhere. Thanks Andrew. Advice well taken and I'll be sure to consider giving that a try. -- 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
Updating GUI during long operation
Hey list, I have a separate thread from the main loop that performs some long and resource intensive operation. The GUI displays an animated GIF while this process takes place via Gdk.PixbufAnimation. Sometimes the animation and the rest of the GUI is very slow to repaint and respond to other event messages. What is the best way of giving the message pipeline a breather every now and then from outside of the main thread? I was using GObject.idle_add(self._updateGUI, ...) within the worker thread to specify a function to be called regularly that could provide some other GUI related update tasks, including the following within it... # Pump the Gtk+ event handler... while Gtk.events_pending(): Gtk.main_iteration() However, my application will crash if I do this with a stack overflow within updateGUI. I'm assuming that since idle_add posted the message to call the updateGUI callback, when the callback is invoked and tries to pump the message pipeline, the method is invoked again because it still hasn't cleared itself from the queue. I could have tried this aforementioned event pump from outside the updateGUI callback and done it from within the worker thread, but I didn't know if that was thread safe to do. -- 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: Updating GUI during long operation
On Sat, 2013-04-20 at 23:35 +0100, Chris Vine wrote: If you have a main loop running, this is completely unnecessary, unless you are doing something to block the loop, which you shouldn't do. Hey Chris. Although your response was not particularly constructive, I'll give you the benefit of the doubt. Perhaps I am doing something unnecessary to block the loop which I should not do. Take a look at the method defined at 287: http://rod.gs/Sio -- 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
Gdk PixbufAnimation supported formats
Hey list, I'm having some difficulty trying to track down the animated file formats supported by gdk_pixbuf_animation_new_from_file(). I am using the function via PyGI / GObject introspection. I know for a fact that it supports animated GIFs, but beyond that, I do not know (e.g. MNG? APNG?). GIF works as a last resort for my purposes, but the constraint of 256 colours is rather limiting. I've tried looking through the Gtk+ source in gdk/* and gtk/*, but maybe I've just been looking in the wrong places. I also tried looking through what relevant documentation I could find on the Gdk's C API, and didn't manage to find what I needed. I'm guessing that perhaps this is because the actual loading is deferred to some other lower level external backend to Gdk, such as Cairo, but I'm speaking from ignorance. The reason I ask is I'd like to use some simple animation in my Gtk+ 3 / PyGI application. The animation is really too simple to warrant Clutter or GStreamer, but enough to at least need basic transparency and preferably 8 bit colour. If anyone has any other suggestions, I'm all ears. 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: Gdk PixbufAnimation supported formats
On Thu, 2013-04-18 at 09:31 +0200, Tadej Borovšak wrote: Gtk+ uses gdk-pixbuf [1] library to load/store images. You can check what image formats your library supports by calling gdk-pixbuf-query-loaders [2] utility. Thanks Tadej. It looks like the only format that supports animation that I can see on my system, and perhaps everywhere at best, is GIF. Do you have any suggestions for another approach to a simple animation that supports transparency and more than 8 bit colour? -- 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: Gdk PixbufAnimation supported formats
On Thu, 2013-04-18 at 10:22 +0200, Nicola Fontana wrote: Hi Kip, my best suggestion is not to use animations: I hate moving things in apps and I'm pretty sure I'm not alone. Hey Nicola. I hear you and I'm sure a lot of people agree. In this case, it's a user interface consideration that I think would add some simple eye candy that an end user without your level of experience and preferences might appreciate. Many other platform desktop environments, e.g. w32 and OS X display simple animations in the shell while transferring files, burning a disc, or what have you, and in many cases, users of such environments form a sizable component of my target demographics so I need to be mindful of them too. Given that, years ago I used a GTK+2 burning front-end [1] that integrated a libmng [2] animation while burning. It is coded in C though. Yes, that's a good example. Sadly I'm using PyGI in a runtime environment that can depend on nothing other than the stock runtimes that come preloaded on the most common distros. Keep in mind IMO the PNG animation status is moribund. I agree and believe that MNG and APNG are both dead or dying. I wish there was a better way to do this that I knew about. -- 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
Gtk.Assistant
Hey list, I'm having issues with my Gtk+ assistant displaying the Finish button prematurely. Under what conditions is the Finish button made visible? I am using Python 3 and Gtk+ 3 via the GObject introspection interface. -- 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
Retrieving process ID from Vte.Terminal
Hey list, I am using Python 3 with GObject introspection over Gtk+ 3 to create a Vte.Terminal widget. Up to date and reliable documentation on this widget is scarce. If one uses the fork_command_full() method to create a child process in the aforementioned terminal widget, how does one then retrieve the child process ID? Version 0.26 of the Vte.Terminal documentation claims there is a 9th parameter to fork_command_full() method which is used to store the child's process ID, but my implementation claims there is no such parameter. Maybe it was removed. Any help appreciated. PS Please remember to cc me. -- 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
gi._glib.GError: Invalid object type `VteTerminal'
Hey list, I've created a window through Glade 3.12.1 which contains a VTE widget within one of its sizers. It looks fine in Glade, but when I attempt to call the builder's add_from_file(Gooey.glade), I get the following error at runtime: $ ./Main.py Traceback (most recent call last): File ./Main.py, line 194, in module navigator = NavigatorApp() File ./Main.py, line 48, in __init__ self.builder.add_from_file(../Gooey/Launcher.glade) File /usr/lib/python3/dist-packages/gi/types.py, line 43, in function return info.invoke(*args, **kwargs) gi._glib.GError: Invalid object type `VteTerminal' I am using Python 3.2.3 with binding for Gtk+ version 3.4.2. This is strange because I am pretty sure I am importing the necessary modules prior to loading with builder via the following: from gi.repository import Gtk, Gdk, GObject from gi.repository import Vte, GLib Any help is appreciated. I'm finding the documentation on programming Gtk+ 3 via Python 3 scant. Not to mention distros compounding the difficulty frequently with old packages / bindings. Something that might help would be a simple minimal that instantiates a Glade defined VTE widget using Python 3 / Gtk+ 3. Thanks for any 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
