Re: gtk_widget_set_size_request stopped working with GTK3

[Tristan Van Berkom <tvb gnome org>]

On Fri, Oct 5, 2012 at 1:57 AM, Steffen Gutmann <muibase yahoo com> wrote:
> 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.

I disagree with this.

What we definitely want to avoid in GTK+, is overextending the API
in ways that only apply to special case configurations (remember that
in most cases, once you introduce a new API it can not be removed in
a later release, this imposes more and more constraints on code
maintainability in the long term).

i.e., it's already annoying that "pixel-size" only applies to an icon loaded
from the icon theme (and so if we were to add some scaling/cropping
features that are more general, it would be better to deprecate the pixel-size
property if the same effect can be achieved with a newer API).

It's a priority for the API to be readable, and to avoid additions of
properties which introduce 'crowding' into the api, we should keep
GTK+ API as short and sweet as possible. Yes, that requires more
thought and consideration when writing platform code, that pays
off when the user is satisfied that user facing apis such as "pixel-size" does
what it says; regardless of other property settings.

If for instance, it is not possible to respect a property for a
given configuration of a widget, or it clutters the code to much and the
code becomes unreadable due to the attempt to manage all configurations,
then a good approach to that problem is to introduce subclasses to
handle that in a sensible way (i.e. it would have probably made sense
originally that only the GtkImageIconTheme subclass exports a
'pixel-size' property)

Like for instance, how we've split out the convenience apis for
GtkComboBox into a separate GtkComboBoxText class.

For now I think we've taken up enough valuable list space and
should probably move this conversation to the bug report.

Regards,
                -Tristan

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