From: Nigel S. a. F. S. <ni...@ni...> - 2003-12-16 10:40:21
|
According to the comment in freeglut_state.c /* * There is considerable confusion about the "right thing to * do" concerning window size and position. GLUT itself is * not consistent between Windows and UNIX/X11; since * platform independence is a virtue for "freeglut", we * decided to break with GLUT's behaviour. * * Under UNIX/X11, it is apparently not possible to get the * window border sizes in order to subtract them off the * window's initial position until some time after the window * has been created. Therefore we decided on the following * behaviour, both under Windows and under UNIX/X11: * - When you create a window with position (x,y) and size * (w,h), the upper left hand corner of the outside of the * window is at (x,y) and the size of the drawable area is * (w,h). * - When you query the size and position of the window--as * is happening here for Windows--"freeglut" will return * the size of the drawable area--the (w,h) that you * specified when you created the window--and the coordinates * of the upper left hand corner of the drawable * area--which is NOT the (x,y) you specified. */ However, the problem I have is related to switching between fullscreen mode and windowed mode. I ask FreeGLUT for the x,y position of the window before going into fullscreen mode, then reposition the window to x,y when returning to windowed mode. However, FreeGLUT is returning the position of the client area via glutGet. Then passing these same numbers into glutPositionWindow() positions the window slightly below and to the right (because glutPositionWindow treats the top left of the window decorations as the reference point). Toggling between these, eventually the window marches off the bottom/right side of the screen... :-( On win32 with GLUT, no such problem! This adjustment logic seems to date right back to rev 1.1 July 2001, can anyone guess why glutGet(GLUT_WINDOW_X) and glutGet(GLUT_WINDOW_Y) should refer to the client area, rather than the true application window position? GetWindowRect( fgStructure.Window->Window.Handle, &winRect ); /* * ...then we've got to correct the results we've just received... */ if ( ( fgStructure.GameMode != fgStructure.Window ) && ( fgStructure.Window->Parent == NULL ) && ( ! fgStructure.Window->IsMenu ) ) { winRect.left += GetSystemMetrics( SM_CXSIZEFRAME ); winRect.right -= GetSystemMetrics( SM_CXSIZEFRAME ); winRect.top += GetSystemMetrics( SM_CYSIZEFRAME ) + GetSystemMetrics( SM_CYCAPTION ); winRect.bottom -= GetSystemMetrics( SM_CYSIZEFRAME ); } |
From: Nigel S. a. F. S. <ni...@ni...> - 2003-12-30 03:05:51
|
> This adjustment logic seems to date right back to rev 1.1 July 2001, > can anyone guess why glutGet(GLUT_WINDOW_X) and > glutGet(GLUT_WINDOW_Y) should refer to the client area, rather > than the true application window position? Are there any objections to changing freeglut to return the application window position on Win32, rather than the position of the client area? Two reasons: 1. GLUT compatibility 2. Make it possible for client code to move a window to a previously known position. We would be parting from a documented decision: * Therefore we decided on the following * behaviour, both under Windows and under UNIX/X11: * - When you create a window with position (x,y) and size * (w,h), the upper left hand corner of the outside of the * window is at (x,y) and the size of the drawable area is * (w,h). * - When you query the size and position of the window--as * is happening here for Windows--"freeglut" will return * the size of the drawable area--the (w,h) that you * specified when you created the window--and the coordinates * of the upper left hand corner of the drawable * area--which is NOT the (x,y) you specified. Nigel |
From: Richard R. <sf...@ol...> - 2003-12-30 04:54:44
|
On Tue, Dec 30, 2003 at 02:07:33PM +1100, Nigel Stewart and Fiona Smith wrote: > >This adjustment logic seems to date right back to rev 1.1 July 2001, > >can anyone guess why glutGet(GLUT_WINDOW_X) and > >glutGet(GLUT_WINDOW_Y) should refer to the client area, rather > >than the true application window position? > > Are there any objections to changing freeglut to return > the application window position on Win32, rather than the > position of the client area? Doesn't this conflict exactly with the point of comment? As I read the comment, it was felt that this was the only way to proceed on the X11 branch, and the WIN32 branch is merely conforming in order to make GLUT system independant. (I do not recall seeing the discussion, nor seeing it cited, nor do I know X11 well enough to say much more.) You could change this on the WIN32 branch, but "freeglut" applications (as opposed to WIN32-only freeglut applications) still could not any more reliably do what you want, and in fact would diverge more in their behavior. (I do object to introducing incompatibilities.) Am I missing something? -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Nigel S. a. F. S. <ni...@ni...> - 2003-12-30 05:28:10
|
>> Are there any objections to changing freeglut to return >> the application window position on Win32, rather than the >> position of the client area? > > > Doesn't this conflict exactly with the point of comment? > > As I read the comment, it was felt that this was the only way to > proceed on the X11 branch, and the WIN32 branch is merely conforming > in order to make GLUT system independant. (I do not recall seeing > the discussion, nor seeing it cited, nor do I know X11 well enough to > say much more.) > > You could change this on the WIN32 branch, but "freeglut" applications > (as opposed to WIN32-only freeglut applications) still could not any more > reliably do what you want, and in fact would diverge more in their > behavior. (I do object to introducing incompatibilities.) > > Am I missing something? The proposal here is that the freeglut convention should follow the GLUT convention. That is, on windows, glutGet(GLUT_WINDOW_?) returns the position of the application window (rather than the OpenGL client window). This way there is correspondance between glutGet(GLUT_WINDOW_?) and glutPositionWindow - the postion of a window can be remembered by the application, and later restored. The point is that freeglut is already system-independent in the sense that glutPositionWindow is application window relative on Win32 and (apparently) client area relative on X11. Overall, I find it preferable that position 0,0 has the application window sitting in the top left corner, rather than the client area. I would be surprised if X11 truely couldn't support that. The symptom I'm having is do to with a facility to toggle between windowed and fullscreen modes. I can't properly reposition the window in the transition from fullscreen. As I toggle, the window marches towards the bottom right... Nigel |
From: Richard R. <sf...@ol...> - 2003-12-30 07:18:26
|
On Tue, Dec 30, 2003 at 04:29:47PM +1100, Nigel Stewart and Fiona Smith wrote: > > >> Are there any objections to changing freeglut to return > >> the application window position on Win32, rather than the > >> position of the client area? > > > > > >Doesn't this conflict exactly with the point of comment? > > > >As I read the comment, it was felt that this was the only way to > >proceed on the X11 branch, and the WIN32 branch is merely conforming > >in order to make GLUT system independant. (I do not recall seeing > >the discussion, nor seeing it cited, nor do I know X11 well enough to > >say much more.) > > > >You could change this on the WIN32 branch, but "freeglut" applications > >(as opposed to WIN32-only freeglut applications) still could not any more > >reliably do what you want, and in fact would diverge more in their > >behavior. (I do object to introducing incompatibilities.) > > > >Am I missing something? > > The proposal here is that the freeglut convention should follow > the GLUT convention. That is, on windows, glutGet(GLUT_WINDOW_?) And if GLUT on X11 does what freeglut now does? Then freeglut would now be in as much GLUT conformance as after the change, wouldn't it? > returns the position of the application window (rather than the > OpenGL client window). This way there is correspondance between > glutGet(GLUT_WINDOW_?) and glutPositionWindow - the postion of > a window can be remembered by the application, and later restored. > > The point is that freeglut is already system-independent in the > sense that glutPositionWindow is application window relative on > Win32 and (apparently) client area relative on X11. I would rather close this gap than widen it. Can we make glutPositionWindow() behave the same on both systems? > Overall, I find it preferable that position 0,0 has the application > window sitting in the top left corner, rather than the client area. I don't care all that much. As long as it is reliable and not terribly messy in the code, either way is perfectly fine with me. > I would be surprised if X11 truely couldn't support that. It would be nice to be able to re-examine the discussion and see why the comment was made that it can't properly be done on X11 the way that you want it for WIN32. I don't know X11 well enough to be sure what the issue is. I suspect that it is tied into the fact that X does not dictate a window manager (unlike WIN32) and window managers are quite varied in their behavior: My preferred window manager does not offer a close-box for windows, but does put a border and titlebar on them, and provides iconification and resizing controls. I've seen some that add a close-box. I've seen some that don't do titlebars. I've seen some that put the titlebar on the side of the window. I even think that I've seen one that dynamically puts the titlebar on the top OR the side, depending on the current window size and title length. Because the issue was apparently hashed out at some length before, and a compromise was reached, I'd like to be able to review the debate to make sure that I understand the objection. The comment in the sources does not seem to fully explain the issues, but only hints. > The symptom I'm having is do to with a facility to toggle between > windowed and fullscreen modes. I can't properly reposition the > window in the transition from fullscreen. As I toggle, the window > marches towards the bottom right... Won't it work to add a fudge-factor? This is no less portable than relying on a WIN32-specific tweak to the freeglut library. Alternately, you could record the difference between requested window configurations and actual (as by glutGet()) and compute a "live" delta value. (Update it everytime you change a window...) (Another way would be to expose the freeglut window handle in some way so that client code could use freeglut as a spring-board to handle most basic things, then get the window-system-specific window handle in order to do non-portable things.) -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Richard R. <sf...@ol...> - 2003-12-30 15:08:39
|
On Tue, Dec 30, 2003 at 01:18:23AM -0600, Richard Rauch wrote: [...] > > Overall, I find it preferable that position 0,0 has the application > > window sitting in the top left corner, rather than the client area. > > I don't care all that much. As long as it is reliable and not terribly > messy in the code, either way is perfectly fine with me. [...] ...that is, as long as it works the same on all supported freeglut systems, is reliable, and is not terribly messy. (^& -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |