Re: Minimum height for minimum width - reprise

[Pietro Battiston <me pietrobattiston it>]

Hi Tristan,

thank you for your clarification. I seem to understand there is
currently no real answer to my needs, but let me stress a couple of
points just to be sure I was clear:

Il giorno mer, 19/06/2013 alle 23.00 +0900, Tristan Van Berkom ha
scritto:
> On Wed, Jun 19, 2013 at 10:13 PM, Pietro Battiston
> <me pietrobattiston it> wrote:
> > Il giorno mer, 19/06/2013 alle 20.03 +0900, Tristan Van Berkom ha
> > scritto:
> > > On Wed, Jun 19, 2013 at 6:19 PM, Pietro Battiston <me pietrobattiston it> wrote:
> > > > [...]
> > > > This is, to my eyes, the clearest example of height-for-width space
> > > > management... and as far as I understand, it is currently impossible.
> > > >
> > > > Am I missing something?
> > >
> > > This is possible, but I don't know any widgets which do that, that's all.
> > >
> > > void
> > > widget_get_preferred_height_for_width (GtkWidget *widget,
> > >                                                             gint width,
> > >                                                             gint *minimum,
> > >                                                             gint *natural)
> > > {
> > >    /* You are going to be allocated 'width' which is something greater
> > >     * than the minimum width you reported in
> > > get_preferred_width_for_height( height = -1);
> > >     */
> > >
> > >    /* Now you will *request* this much height */
> > >    *minimum = height;
> > >
> > >    /* Note that 'natural' must be at least as big as 'minimum' */
> > >    *natural = desired_height_for_given_width (height);
> > >
> > >    /* Now you will *request* this much height */
> > >    *minimum = *natural = height;
> > > }
> > >
> > > Note that you might be allocated more size than that which you requested,
> > > but not less.
> > >
> > > You might want your aspect ratio height to be the minimum & natural
> > > instead of 'square', depending.
> > >
> > > Does this answer your question ?
> >
> > Well, this did suggest to me that my question was maybe not well
> > formulated - in fact, I have a problem with the layouting algorithm, not
> > with the working of a widget on its own. So consider this simple
> > example:
> >
> > 1) in my widget_get_preferred_width(), I set
> >    *minimum = 50
> >    *natural = 200
> >
> > 2) in my widget_get_preferred_height_for_width(), I set
> >    *minimum = *natural = 10000/width
> >
> > 3) I pack_start this widget into a Gtk.VBox()
> >
> > 4) I add the VBox in a Gtk.Window, and show_all() it
> >
> > Result: a window that's 200x200 (and the user can't shrink vertically).
> >
> > Now repeat the steps above, adding, between 3 and 4:
> >
> > 3a) I pack_start into the VBox an additional 60x17 GtkLabel (or
> > GtkImage, that's irrelevant).
> >
> > Result: a window that's 200x183!
> >
> > So to resume: what annoys me - in both cases - is that the window is
> > much too tall, and the user cannot even shrink it vertically.
> > But what I really find inconsistent is that by adding a widget below,
> > the resulting window may become smaller!
> >
> > Anyway, I don't have a better algorithm in mind - if you tell me that
> > there is nothing I'm missing and there is no obvious solution to such
> > problem, I'll just make things work reasonably in reasonable contexts.
>
> It sounds like you're running into some issues with how the toplevel
> decides to allocate the default size.
>
> When I wrote height-for-width, I made sure the default size was
> minimum height for minimum width, and then ensured that labels
> requested a reasonably large minimum width by default (unless
> the user sets width-chars explicitly to a small value).
>
> This has been changed in GTK+ and I'm not sure what the details
> are exactly now, first the trick I played to ensure labels were
> reasonably wide by default was removed (resulting in some tall
> dialogs with wrapping text in 3.2 or 3.4), now there is some other
> logic/priority used to guess an appropriate window height (and
> I think that's changed very recently, Matthias and Benjamin have
> been fixing GtkWindow default sizes afaik so they would be able
> to better comment on this).
>
> However I think that what you are trying to do is a bit application
> specific and not necessarily in the right place.
>
> The layouting code is used to share space in what is allocated
> in a toplevel window (and define some minimums, those minimums
> should really be the minimum required to display some content).


My problem is precisely here: the minimum width I declare _is_ the
minimum required to display the content, and the same holds for the
minimum height I declare for that width. But that _doesn't_ mean that
those minimums should for any reason be considered a "canonical"
allocation of any sort. A better rule of thumb would be in my opinion
"natural width x minimum related height". It would still be, strictly
speaking, a minimal allocation, and presumably one with a more decent
aspect ratio.

> If there is no left over space in your application (i.e. no scrolled window,
> no area where it is useful to put extra space and then sacrifice some height
> if the window is too 'slim' to fit other content), then height-for-width is
> not really for you.

My impression is that I'm not _enough_ application specific! It's true,
in my simple testing application I have no left over space. But my main
idea for my size requests was in fact:
1) I want my widget to play nicely when a user resizes the toplevel
window, without reading the mind of the user in advance,
2) I want my widget to play nicely even contained in complex layouts
which I cannot know ex-ante.

To be honest it is a bit sad to hear that I should model the behaviour
of my widget on the test window... that's just a test window. I would
like my widget to really be able to exploit the height-for-width
paradigm.


> What you probably want, is a widget which requests 1x1 width & height,
> and is placed in a position where it will receive expand space in both
> axis... after allocating you then decide to draw whatever fits in the
> space you were allocated, centering  it and drawing it with the desired
> aspect ratio (as for example, totem movie player would do with it's
> gstreamer widget to fit a scaled video surface into the area available
> while preserving the aspect ratio).

I don't want to force an aspect ratio on the user, I want to suggest one
and then to adapt to whatever is needed. This is, in my mind, the
meaning of words "natural" and "minimum". But I will stop now pretending
that the general layouting mechanism should be changed, since apparently
my widget is the only one getting into troubles.

Thanks for all the clarifications,

Pietro