Re: set_resize

["Kalle Vahlman" <kalle vahlman gmail com>]

2009/1/14 Pietro Battiston <toobaz email it>:
> Il giorno mer, 14/01/2009 alle 17.20 +0200, Kalle Vahlman ha scritto:
>> 2009/1/14 Pietro Battiston <toobaz email it>:
>> > I would have filed a bug (asking for windows to clip to screen when
>> > their their size_request is too big*), but it's obviously a major issue,
>> > so obviously it can't be true that nobody thought about it.
>>
>> Clipping a window is dangerous, since it can obscure controls so that
>> you can't reach them at all any more. If the window expands to
>> infinity, you can at least move it partially offscreen to reach the
>> other end.
>
> I thought "the user will just resize it (dragging it out of the screen
> above/at right) and then do what you want", but I realize now that if
> resize is forbidden to the user it is indeed a problem.

Yeah, dialogs suck often with this for low y resolutions, the action
buttons are offscreen.

There's also a possibility for fighting if setting the size by the
progam is clipped and setting it by hand does not (you resize the
window, content resizes so program reacts by setting the size -> back
to original).

>> Forcibly clipping window size would anyway only be band-aid to the
>> real problem in the application, which can be:
>>  - it doesn't adapt the size of a window for small screens (a minor,
>> but unfortunately common issue which can be worked around by moving
>> the window partially offscreen)
>>  - it doesn't constrain the size of a dynamically resizing widget
>
> I don't see how this is a problem; instead, it is where my question came
> from: I had a ScrolledWindow which I wanted to be as big as possible,
> but not as big as its child if that meant overflowing screen.

I don't think the program should be making that decision. Most window
managers have a maximized state for the windows, which (assuming the
widgets are packed right) should give your scrolled window as much as
it can have. Otherwise, the user likely didn't want the window filling
the screen so forcing the window to be large is not going to make
him/her happy.

>> One point to notice also is that knowing the size of window
>> decorations is a window manager dependant feature so it can't really
>> be trusted to be always available.
>
> Well, OK, this is a strong point, I tried my horrible hacks only with
> metacity and didn't know they where not portable.

Well, they are portable to any WM supporting the relevant part of the
EWMH spec, namely:

  http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507876

Not sure of other platforms, but I suppose there should be Windows and
OSX implementation for this:

  http://library.gnome.org/devel/gdk/stable/gdk-Windows.html#gdk-window-get-frame-extents

> If, as I imagine, a window manager has no way to say "no, app, I won't
> give you all the space you requested but only the available size", then
> the answer to my doubt is complete...

Quite the contrary, the window manager is the authority on window
size. Metacity happens to just be liberal with granting the requests.
But take a tiled&tabbed window manager like ion for example, it
divides the screen space into boxes the user controls and applications
have no say in the window size at all.

So while setting sensible minimum sizes and constraining maximum by
ellipsation or scrolled container for your *widgets* makes totally
sense (to ensure the application will be usable on the first run),
taking over the window management by controlling the *window* size
really isn't worth the effort. It only brings
error possibilities and since you never really can trust the window
manager (not to mention the user) to grant your request anyway...

-- 
Kalle Vahlman, zuh iki fi
Powered by http://movial.fi
Interesting stuff at http://sandbox.movial.com
See also http://syslog.movial.fi