Re: Minimum height for minimum width - reprise

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
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
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.

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

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

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,


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]