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 :-) On ב', 2013-06-17 at 19:32 -0700, Kip Warner wrote: > 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... > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
