GNOME.org
 

Re: Minimum height for minimum width - reprise

On Sun, Jun 23, 2013 at 4:50 PM, Pietro Battiston <me pietrobattiston it> wrote:

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,


Hi Pietro.

As I've mentioned before, other people have been playing with tactics
to "guess" a good size for the toplevel window (poke poke, jump in any
time guys)... I'm not exactly aware of what the final decision was for
how to guess what the default size will be.

However, you need to take into account that we are stuck with a pretty
rigid API regarding toplevel window constraints (those are XLib APIs
that GtkWindow needs to honor in order to "play nice" with a window
manager).

I have a feeling that your requirements are... falling into that pitfall,
i.e. the height-for-width requesting algorithms don't fit cleanly into
what we report to the X server as minimum sizes for width and height.

Some things are clear, for instance the minimum width of the X window
should not ever be the natural width of the GTK+ widget's request
(that would make it impossible to shrink the width of the window below
the natural request, rendering the difference between minimum and
natural sort of inconsequential and useless).

Other things are not so clear, unfortunately, we've had a difficult time
finding a real solution to this problem (and I *think* that some people
have spent real time considering a good solution for toplevel default
window sizes, particularly just now in the beginning of the 3.9 cycle...
this interests me as well, so again, guys... please ring in and let us
know how it is intended to work, or let us know if this is still undetermined).

Cheers,
    -Tristan
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]