Re: A question about box packing and widget/window sizing..

[Owen Taylor <otaylor redhat com>]

"Daniel J. Kressin" <kressd11@sol.acs.uwosh.edu> writes:

> On 2 May 1999, Owen Taylor wrote:
> [snip]
> >
> >Note that your constraints actually constrain the possible sizes
> >of the toplevel window - so if you don't want to play some
> >game with the user of "no, you can't have that size", you
> >need to tell the window manager about the constraints.
> >
> [snip]
> >
> >I think the following should achive exactly the effect you
> >want:
> >
> > GdkGeometry geometry;
> >  
> > geometry min_aspect = 1.0;
> > geometry max_aspect = 1.0;
> >
> > gtk_window_set_geometry_hint (toplevel, drawing_area,
> >                               &geometry, GDK_HINT_ASPECT);
> >
> >The key here is the geometry_widget argument; if this
> >is non-null then the constraints refer not to the toplevel
> >as a whole, but to subwidget of the toplevel.
> 
> This doesn't work.  In fact it causes the following odd results:
> 1) Neither NULL nor a non-null value as the geometry_widget arg constrain
> the drawing area ("d_a") or the toplevel window at all.
> 2) Scenario: Executable W (with the above code), Executable WO (without 
> the above code), both running on (Linux) machine A.
>   Case 1 - Display on X server running on A:  WO gives the expected window
> contents, with no constraints on size.  W gives a window containing *only*
> the title bar (no packing table, no d_a), and what *would* be the
> background (gray rectangles) of the window, offset about -10, -10 relative
> to the "title bar window".  Any attempt to resize W results in a core dump
> with a BadAlloc. (It appears to be trying to alloc a backing pixmap
> roughly 65000 x -10 for some reason.)
>   Case 2 - Display on X server on a Win95 machine (Astec-X 2.12 trial): W
> and WO both display fine, with the expected window contents, again with no
> constraints on size.
> 
> Truly bizarre.  Any insights?

Sure. I investigated this bit, and found a number of things.

 1) For an aspect ratio of 1.0, GTK+ uses a ratio of 
    MAXINT:MAXINT. Although it's legal, it gives fvwm
    fits because of the way it does its calculations.
    (This is why you saw the weird effect where the contents
    popped out of the fvwm frame)

so, I changed that to 1000:1000, and found:

 2a) fvwm and twm get the aspect ratio calculations wrong anyways - 
    they don't take into account the base size fields and
    just constrain the overall window size to that aspect ratio.

 2b) WindowMaker also gets the aspect ratio calculations wrong for 
     a more amusing reason - it apparently switches 
     base_width and base_height somewhere in its calculation.

It sounds like the Astec X server might not obey the 
aspect ratio hints at all.

Enlightenment does get it right, so there are window managers
that will produce the desired effect; though there are a couple
of GTK+ quirks that you have to take care of; the notable
one being that you need to specify a base size as well
as the aspect ratio.

the conclusion of all this is that you probably are
best off not using this tactic ;-)

As an alternate suggestion, try putting your drawing area
inside a GtkAspectFrame. That was my very first GTK+
widget, and designed for almost exactly this purpose.
It won't constrain the size of the toplevel window, but
the drawing area will be a square inside of whatever
area it gets in the end.

Regards,
                                        Owen