the documentation for gtk_widget_size_request () says:

"Also remember that the size request is not necessarily the size a
widget will actually be allocated."

While there may be a lot of reasons why a widget doesn't get the area
requested, I imagine(d) the basic one would be "because there is not
enough space on the screen for everyone".

Instead, size_requests are indeed fulfilled at cost of greating a window
much bigger than the screen. Then, I frankly don't see the point of
set_size_request (but I understand why it's very rarely used!).

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. However, I
wasn't able to find any reasoning about it, even on this mailing list.
Is the problem that it would break too much existing code, or is there
some deeper reason for the current behaviour?
Or is this just a window manager (metacity in my case) issue, not
treated by gtk?

(what I would expect is:
1) the GtkWindow calculates its size_request
2) if it's bigger than the available size, it clips it. Then it resizes
3) if in this resize process the window went outside the screen (because
it wasn't positioned in the topleft corner), it moves left/up as much as
is needed

as far as I know it would be possible to accomplish 2) in gtk and 3) in
the window manager.)

(Notice that - still as far as I know - getting a window, or a contained
widget, to take the available space without overflowing the screen is
_very_ tricky.)

Pietro Battiston

Attachment: signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente

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