There’s been an odd case that I’ve not seen one window manager be able to handle correctly. It’s the case where you are required to resize a window to be smaller than than it’s defined minimum size, because you are tiling it, semi-maximizing it or maximizing it. Basically attempting to fit a big object into a small space because the user requested it.
Compiz hasn’t really handled this case all that well in the past – the default behavior (after staring at the code some time) seems to be to try to get as much of the window on-screen as possible, so if the top is offscreen move it down, if the bottom is offscreen move it up. Unfortunately this solution isn’t perfect, and it lead to an interesting bug where doing anything to restack the window would cause it to jump around, because if it wasn’t partially offscreen one way, it was partially offscreen the other and compiz would try to re-adjust that part to bring it back on screen.
For now what I’ve done is followed the good advice given to me by Jason Smith and disabled vertical or horizontal maximization in cases where it is not possible to sanely maximize that window. And in multimonitor cases, we now try to maximize on the monitor the window is most on first, and failing that, the closest possible monitor that can accomadate the minimum size of that window.
Of course, this solution isn’t perfect either … now instead of explaining to users why parts of their window aren’t visible when they are maximized or tiled I now need to explain why some windows show the maximize button on small resolutions and others don’t.
This got me thinking though, what is the best way to handle this case? I’d like to be able to fit my huge window into a small space, but I need a way to get at all of its contents. I guess there are a couple of ways of doing it.
- Clip the drawing of the window using OpenGL and allow the user to alt-drag the window around withing the constrained box such that the visible parts of the window never leave the box. This would be the easiest thing to implement but it’s not obvious how it would work
- Clip the window within its frame and allow it to pan around inside the frame. This is a much prettier solution, we could even have things like scrollbars for the window or some mouse actions to pan the window around. Of course, it requires a LOT more work in core and heavily breaks the assumption that the window is always going to be within the same place in its parent window
- Scale the window down so that the user can see everything, scale it back up again on hover and use the mouse to pan it around (sort of like a mini-zoom). I guess this is possible, but not without some hard work because of the lack of input transformation in X.
Alternative Fax 
I have been experiencing this problem since I got my eee.
Have you used Opera Mini? (They have an emulator in the homepage if you haven’t).
You have to show a big webpage in a small screen, you first see a small view of the full page and with the mouse/a square you zoom in that zone.
I’m not sure if that approach is 2,3 or a mixture of both.
In any case I will be glad enough with any solution. If you need testing with the 1 (as you say you don’t know how will it work) I’ll be happy to help.
But the problem depends on different version of Compiz. As my experience, since Compiz version 0.8.6, this problem is much better handled.Ubuntu 10.10 carries 0.8.6 and on which you can scale your screen to a size smaller than your window size. Compiz can handle it correctly.
However, RHEL6.1 which carries Compiz 0.8.2 can not handle this case correctly. Even you scale back to where you are, you lose your opened window.
Besides, would you mind me post this to my wordpress ?