Re: gtk_widget_set_size_request stopped working with GTK3

[Steffen Gutmann <muibase yahoo com>]

Hi Tristan!

> Right, the bug might have to do more with cropping/scaling support

> GtkImage, rather than it's size request.

Filed as [Bug 685506] New: GtkImage and size/space management

>>  Regarding size request:
>> 
>>  We add a new property of type boolean to GtkImage.  If it is set (default), 
> the size request for GtkImage will be the size of the underlying image (or the 
> pixel-size), i.e. the exact same behaviour as it is now.  If it is set to FALSE 
> then the minimum size will be (1, 1) and an application can use 
> "width-request" and "height-request" for making the widget 
> size larger.  I am not sure what a good name for this new property would be, but 
> maybe you have a suggestion?.  Something like "min-size-is-image-size" 
> would probably make the property self-explanatory but is obviously too long 
> compared to other existing property names.  Maybe "full-image" or 
> "image-size-request"?

Any comment about how to allow a smaller size request?  Any good name for this property?


>>  Regading placement:
>> 
>>  In GTK2, GtkImage cropped the image such that only the center is shown, 
> i.e. it took off an equal amount of image content on the left and right, and top 
> and bottom.  It probably just sets the right clipping mask when drawing the 
> image for achieving this.  We could simply use the same policy, or we modify the 
> usage of GtkWidget's "halign" and "valign" properties.  
> Currently the docs reads:
>> 
>>  "halign" GtkAlign : Read / Write
> 
> While it's true that the align properties make no sense when the
> widget's natural size is equal to,
> or exceeds the widget's allocation; 

From a programmer's point of view, the align properties also make sense when the widget size is smaller than its allocation.
For example, for centering, one would draw the contents at (allocation.width/height - contents.width/height) / 2 which works in both cases, when there is extra space as well when there is insufficient space (assuming clipping is done by cairo correctly).


> I'm not exactly sure it's a good
> idea to use the GtkWidget's
> halign/valign properties directly (i.e. it's like hidden candy, people
> wont see it evidently in
> the docs/headers for GtkImage and so will probably not discover it).

We could cross-ref the halign/valign properties in the docs of above new property that describes how to obtain a smaller size request for GtkImage.


> However I do like the idea of GtkAlign properties for that, where FILL
> would mean scale
> and CENTER/START/END have the obvious clipping behaviors.


Right.  Actually I tried the FILL alignment with a GtkImage having extra space.  The image becomes centered but not streched.  For keeping compatibility, I guess we want to keep it this way.

> Also, it should have reasonable behaviors defined for the various
> configurations of
> a GtkImage 


I think we are shooting too far here.  For icons and such I think the "pixel-size" property is the right approach and the new property suggested above should have no effect.  Otherwise, if we are trying to support all combinations of configurations, pixel-sizes and the new property then we will likely end up in open problems and the chance that any patch will be accepted is going to be small.

For now, I would document the new property as GdkPixbuf only.  Maybe we can also support the GdkPixbufAnimation.

Best regards,

Steffen