default window position on resize issue with qt (3 or 4), compiz and multiple viewports (desktops)

[David Burrows]

I post this with as much detail as I can collect, as this problem is a difficult one. First it is important to distinguish the difference between multiple virtual desktops and viewports. Virtual desktops are treated as seperate "screens" by QT, so therefore do not exhibit this problem. If you test with KWin or metacity, you will notice this isn't an issue. Also if you test compiz using multiple desktops instead of virtual horizontal/vertical ones then the problem does not appear.

Viewports are a compiz invention, to combine multiple desktops into a single large desktop, to make plugins like the wall and cube work. If you do not do this, when moving a window half way between two desktops, instead of the window appearing on both desktops, it will get truncated.

Reproduce the problem as follows. Start any guest VM, it will create an initial window (make sure its not full screen or maximised), then switch to another viewport. When the guest resizes its window (eg, changing from BIOS screen to loading windows screen), the window will appear on the currently active viewport, instead of the viewport it was initially created on (before the resize).

I can confirm that the problem is in the function called normalizeGeometry contained in VBox/Frontends/VirtualBox4/src/VBoxConsoleView.cpp on line 921 (svn).. This function is called from the resize event (VBoxDefs::ResizeEventType line 1093), with a default (and unchangeable) parameter of "true". Changing this value to "false" fixes the problem. Obviously this is not ideal, as this will upset the people who complained that sometimes when vbox resizes a window, it goes off the screen. Personally I think if that happens, you should just get over it and use the window move function (right click on the tasks name select move) to move it back on screen again. At the very least, there should be a configurable option (a checkbox) "Place offscreen windows back onscreen again". (To avoid having to do a source compilation to work around this issue)

As for how to fix the problem properly, this is where it becomes far more difficult. Its not QT's job to be aware of what the window manager is doing, how many workspaces there are etc. And its obviously not a portable thing to do anyway (What does this mean on Windows/Mac?).

The normalizeGeometry code uses the window() function to return the position of an uninitialized QWidget object, which defaults to a viewable area within the current "screen" or "desktop". The value of this is then passed to QDesktopWidget::availableGeometry to determine the viewable area where the window should be repositioned.

The problem is, this is not desirable for the compiz/viewport scenario, but works on absolutely everything else. Instead what we need to do, is return a QRect for the "viewport" that the window currently exists on. (No idea how to do this)

Also of note, is that because vbox overrides the window manager's default positioning of the window, you cannot use the window positioning rules in compiz config settings manager to override the default behaviour.

I've spent days on this silly problem, I really wanted to provide a patch to fix it properly but alas it requires further discussion. :(

I hope I have provided enough substance for a proper resolution of this matter, and I thank anyone who wishes to help resolve this for their time in advance. :)

[Dsen]

Hello, Snadge. Thanks for reporting this with such extended description.

This is known problem, moreover this is one of many reported issues with desktop visualizer like compiz or beryl. Just now we are making efforts for releasing 2.0 version with Qt4, there are too many issues concerning porting VirtualBox to newer Qt version and issues of Qt itself, so the main target is to make it more stable on standard window managers but of course this doesn't mean we'll forget about compiz at all. It is quite possible what right after 2.0 release there will be a time to fix issues related to positioning/resizing/seamless/fullscreen features with compiz-like environment and multi-monitor systems.

Concerning normalizeGeometry (true): yes, this method looks like the main problem of most of positioning troubles with different window managers and our extended modes (like fullscreen & seamless). But I can't just change there something without checking the results on most of window managers after change, because of different event sequence under different platforms. So it is a lot of time needed for it.

One more time, thanks for your report. I'll analyze it further in nearest future.

[David Burrows]

Replying to Dsen:

*snip* It is quite possible what right after 2.0 release there will be a time to fix issues related to positioning/resizing/seamless/fullscreen features with compiz-like environment and multi-monitor systems.

Concerning normalizeGeometry (true): yes, this method looks like the main problem of most of positioning troubles with different window managers and our extended modes (like fullscreen & seamless). But I can't just change there something without checking the results on most of window managers after change, because of different event sequence under different platforms. So it is a lot of time needed for it.

I agree this isn't a trivial problem to fix, and there are other platforms and considerations to take into account.

In the meantime, can I re-propose the idea that there should be a checkbox in the configuration for the VM labelled something similar to "On window resize move offscreen windows back onscreen" (which defaults to being ticked or true). This checkbox would have the effect of toggling the parameter to the normalizeGeometry function. There is a strong argument that the application has no real business in determining window placement, that its the job of the window manager. In fact, having the application involved in window positioning then breaks the ability to create custom rules in the window manager, for the user to specify their own window positioning. This is my reasoning as to why this should be configurable, everyone is happy then, including the people who complain that the window can sometimes go offscreen.

I have spoken with compiz devs about this problem as well, and they have proposed an idea for a new compiz plugin, which constrains an applications window movement, to the viewport in which the application is running. Eg, instead of QT seeing the entire desktop containing all the viewports, it only sees the viewport that the application window is on, preventing the resized window from appearing on the active viewport. They have roped me into writing this plugin, so theres a good chance that it might not happen at all.

In any case, I think the checkbox idea to toggle the parameter to normalizeGeometry should be seriously considered for a 2.0 release. Its a minor change, its very unlikely to break anything, and the default for this option is the same as what it is now, and has been for ages. It just gives users like myself, running compiz (and presumably other systems too) an option NOW (uncheck that option) .. as opposed to waiting for a more involved fix, that may or may not come down the track. Besides its not an option for me to recompile the PUEL version like it is the OSE version. :P

Thanks in advance for your time again.

[David Burrows]

*correction* Above I wrote that the checkbox should be an option when configuring the VM. This is actually incorrect. The option should be a global option thats not specific to virtual machines, as it is a parameter of the GUI. It should be in File -> Preferences -> General.