Re: how to determine maximum possible window size?

[Chris MacGregor <chris-gtk-list bouncingdog com>]

On 02/05/2008 08:11 PM, Paul Davis wrote:
> my "portable" way to do it is to ask how big the window is *after* the
> change has taken place, rather than try to guess ahead of time. This is
> particularly important when you want differentiate between "fullscreen"
> and "maximized", which are not necessarily equivalent.

The problem in our case is that we don't want to maximize the window - we want 
to figure out how much we need to scale down the video, if at all (we never 
scale it up), and then let the window be whatever size it needs to be.  If the 
video fits full-size, then we don't really care if the window is smaller than 
the available space - it doesn't need to use all of the space.  If the video 
needs to be scaled down, we don't want to make it any smaller than it needs to 
be, nor can we scale it any less (or the window won't fit).  So what we really
need in our case is a way to find out how big it can be, without the annoying 
visual side-effects of maximizing it and then resizing it to its "real size".

> > Perhaps this is information that GTK *SHOULD* make available to apps - part of 
> > the point is to hide the system-dependent hassles from the app, right?
>
> the information you want to hide is not part of the windowing system
> (X11, win32/GDI, quartz), its part of the desktop system (GNOME, KDE,
> Cocoa+WM etc). GTK itself is a widget toolkit; GNOME provides lots of
> cool libraries (as does KDE and others) to interact with the desktop
> system.

Well, it (well, GDK) does provide gdk_screen_get_width() and 
gdk_screen_get_height().  Unfortunately, it's not clear to me how those are 
useful, unless you're going to be putting up a full-screen window that sits on 
top of everything else, including panels if any.

So I would think it appropriate that it (GDK, I guess) provide (instead of or 
in addition to those functions) functions that return the *available* screen 
size after deducting whatever the underlying window system is providing that 
semi-permanently occupies screen real estate, such as panels/taskbars/etc.  It 
doesn't really make sense to me that the answer is "no, portable GTK-based 
apps must (unportably!!) go around the portability library layers and talk 
directly to the underlying window system to try to figure that out".  I 
understand that the functionality may not be there now, but it seems useful 
enough that it ought to be there.