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
On Wed, Jun 26, 2013 at 2:51 PM, Kip Warner 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 widgets at the botto
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_
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 e
2013/6/24 Andrew Potter :
> # 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 / self.get_aspect
On Sun, Jun 23, 2013 at 10:04 PM, Kip Warner 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 like collapsed:
>
> -- Forwarded message --
> From: Kip Warner
> Date: Fri, Jun 21, 2013 at 4:10 AM
> Subject: Re: Invisible GtkImage
> To: אנטולי קרסנר
> Cc: gtk-app-devel-list
>
>
> On Thu, 2013-06-20 at 17:59 -0700, Kip Warner wrote:
> > On Wed, 2013-06-19
> 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
On Sun, Jun 23, 2013 at 11:17 AM, Kip Warner 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, False, 0)
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
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 wh
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 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
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 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 sim
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 subclass
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 a
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 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 accord
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 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 wan
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 s
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
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
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 t
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 1
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 th
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 i
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 th
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 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, o
On Fri, Jun 14, 2013 at 5:20 PM, Kip Warner 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 height of 32767
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_
On Thu, Jun 13, 2013 at 9:54 PM, Kip Warner 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 toolkit won't b
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
On Thu, Jun 13, 2013 at 8:42 PM, Kip Warner wrote:
> That makes sense, but should the allocation passed to the base class's
> do_size_allocate() be the original allocation parameter that was passed
> into the override, or the one that I modified to contain the new image
> dimensions adjusted to
> 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 knowl
On Thu, Jun 13, 2013 at 6:09 PM, Kip Warner wrote:
> The code mostly works in that I can see that the area the widget is
> taking appears to be the correct size as I resize its parent. However,
> the actual image pixels do not appear to be painted.
>
Hi Kip,
After setting the rescaled image, you
38 matches
Mail list logo
