"This is a fix for the issue reported by Anders a week ago (see \u201c[osg-users] BUG?: mouse coordinate changes after window move\u201d discussion thread on Sept. 20). The issue was that the initial implementation added a few months back was not converting the window coordinates to client-area coordinates resulting in a slight offset each time a decorated window was moved (caused by the window border). This was also causing windows to move out of their assigned screen."
and
"Attached is a fix for the taskbar repaint issue that occurs when a graphics window is toggled from full-screen mode to windowed mode (as identified by Gert van Maren a couple of weeks ago).
Also included is a fix derived from the \u201cEvents from the past\u201d discussion thread that took place on July 11."
Stephan: "attached you'll find some modifications to the GraphicsWindow-class and
their platform-dependant implementations.
The problem:
setWindowRectangle and setWindowDecoration do not update the
traits-object, so, if you call setWindowRectangle on a
not-realized-window it will open with another size when realized later.
getWindowRectangle reports possible wrong sizes if setWindowRectangle
called before.
My solution:
split the implementation in two parts:
GraphicsWindow::setWindowRectangle will update its traits-object and
call afterwards the virtual method setWindowRectangleImplementation
(which is implemented by the derived platformspecific classess). For
setWindowDecoration I am useing a similar mechanism.
I hope you'll find the submission useful, the Win32 and X11 changes are
not tested but should work."
Changes to this made by Robert are call of resized in setWindowRectangle
instead of setting of Traits, and use of a bool return type.
