Hello, 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