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
On Wed, Jun 26, 2013 at 2:51 PM, Kip Warner k...@thevertigo.com wrote:
On Mon, 2013-06-24 at 13:56 -0700, Andrew Potter wrote:
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
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
On Sun, Jun 23, 2013 at 10:04 PM, Kip Warner k...@thevertigo.com wrote:
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
2013/6/24 Andrew Potter agpot...@gmail.com:
# Note here that the minimum request is set to the natural height of
the input pixbuf
# This may not be the desired behavior in all circumstances
def do_get_preferred_height_for_width(self, width):
return (self.pb.get_height(), width /
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
--
From: Kip Warner k...@thevertigo.com
Date: Fri, Jun 21, 2013 at 4:10 AM
Subject: Re: Invisible GtkImage
To: אנטולי קרסנר tomback...@gmail.com
Cc: gtk-app-devel-list gtk-app-devel-list@gnome.org
On Thu, 2013-06-20 at 17:59 -0700, Kip Warner wrote:
On Wed, 2013-06-19 at 14:03 +0300
On Sat, 22 Jun 2013 15:30:34 -0700, Kip Warner wrote:
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.
So how exactly does the behaviour of my
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
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
On Sun, Jun 23, 2013 at 11:05:00AM -0700, Kip Warner wrote:
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:
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
On Sunday 23 June 2013 20:05:00 Kip Warner wrote:
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
On Sun, Jun 23, 2013 at 11:17 AM, Kip Warner k...@thevertigo.com wrote:
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,
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
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.
Try the canvas idea. You can probably use any
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
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.
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
On Sat, Jun 22, 2013 at 01:09:17PM -0700, Kip Warner wrote:
I can't believe resizing a widget in Gtk+ is this difficult.
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.
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
Le 23/06/2013 00:30, Kip Warner a écrit :
On Sun, 2013-06-23 at 00:08 +0200, David Nečas wrote:
[...]
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
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
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
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,
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.
On ג', 2013-06-18 at
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
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
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
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
On Thu, Jun 13, 2013 at 9:54 PM, Kip Warner k...@thevertigo.com wrote:
What you can do to (try to) prevent that situation is to set the widget to
do height for width allocation, and override
get_preferred_height_for_width() to honor your aspect ratio. In some
situations of course the
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:
void
On Fri, Jun 14, 2013 at 5:20 PM, Kip Warner k...@thevertigo.com wrote:
I have three concerns. The first is that sometimes the incoming
allocation has some very strange width and height values in it, but are
usually valid the rest of the time. Sometimes I see values like
width of -408563232 and
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
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
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
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
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
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
39 matches
Mail list logo
