From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-03-12 20:14:30
|
OK, the fix for Windows is in "freeglut_state.c" on lines 384-387, where the left, right, top, and bottom locations of the window are being adjusted. The CVS version has some additional one-pixel offsets which need to come off. (Why I put them on in the first place I will never know.) Incidentally, my Linux results are from the Gnome windowing system. The plot thickens, in a manner of speaking. I tried reducing the window sizes to 30x30 pixels to see exactly what the window size means and I find that it is the usable size without the decorations (by which I mean the borders and the bar on the top). On the Linux systems, both GLUT and "freeglut" give me nice square windows with the decorations outside an obvious 30x30 pixel area. On Windows, GLUT does the same thing as it does on Linux while "freeglut" gives me a window that is 30 pixels high by 104 pixels wide. The 104-pixel width seems to be a minimum from Windows; if I ask for the window's width immediately after creating it the value is 104 pixels. If I click on the corner of the window and try to shrink its width I can't get it any narrower. And if I click on the corner of a GLUT window, the width immediately pops out to 104 pixels and will not get any less than that value. I also found, by the way, that if the mouse leaves a "freeglut" window under Windows its coordinates as passed to the keyboard callback immediately freeze. Under Linux, and with both operating systems under GLUT, the coordinates continue to change and take negative values or values greater than the window size. This also bears looking into. John F. Fay joh...@eg... "It is a poverty to decide that an unborn child must die in order that you may live as you like." - Mother Teresa |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-03-12 21:09:42
|
More info. GLUT on Windows uses the specified position to be the position of the upper left-hand corner of the usable interior. GLUT on Gnome Linux uses the specified position to be the position of the upper left-hand corner of the decorations. Freeglut on Windows imitates GLUT on Windows. Freeglut on Gnome imitates GLUT on Gnome. Do we want it this way, or do we want consistent handling across operating systems? I think I started this thread by noting that GLUT on Gnome Linux returns the position of the usable interior for "glutGet ( GLUT_WINDOW_X )" and "_Y )". So that is inconsistent. GLUT's specified window size indicates the size of the usable interior on both platforms, so there is no confusion there. By the way, what sort of user interface would there be to create a window without decorations? John F. Fay joh...@eg... "It is a poverty to decide that an unborn child must die in order that you may live as you like." - Mother Teresa |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-03-12 21:25:15
|
Steve, The answer to your first point is no, it does not depend on the window title. I took out the title (well, cut it to two characters and then to an empty string) and the minimum width stayed the same. The second point is well taken. I'm working on it. John F. Fay joh...@eg... "It is a poverty to decide that an unborn child must die in order that you may live as you like." - Mother Teresa -----Original Message----- From: Stephen J Baker [mailto:sj...@li...] Sent: Wednesday, March 12, 2003 2:35 PM To: fre...@li... Subject: RE: [Freeglut-developer] Window Positions On Wed, 12 Mar 2003, Fay John F Contr AAC/WMG wrote: > On Windows, GLUT does the same thing as it does on Linux while "freeglut" > gives me a window that is 30 pixels high by 104 pixels wide. The 104-pixel > width seems to be a minimum from Windows; if I ask for the window's width > immediately after creating it the value is 104 pixels. If I click on the > corner of the window and try to shrink its width I can't get it any > narrower. And if I click on the corner of a GLUT window, the width > immediately pops out to 104 pixels and will not get any less than that > value. Hmmm - that probably also depends on the length of the "Title" string. I guess Windoze doesn't like to truncate it. > I also found, by the way, that if the mouse leaves a "freeglut" window under > Windows its coordinates as passed to the keyboard callback immediately > freeze. Under Linux, and with both operating systems under GLUT, the > coordinates continue to change and take negative values or values greater > than the window size. This also bears looking into. That's certainly the desired (and expected) behaviour. You need to be able to click on something and drag it off the edge of a window (for example) - and negative mouse coords are to be expected. Once again, I have no idea what you have to do under Windoze. ---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-03-13 20:58:24
|
I think I got my Linux machine to run KDE instead of Gnome and I am getting the same shift in the window position. So that's both Gnome and KDE. If I may propose a fix, how about this: - Create the window at the user-specified position - Query the position of the window - If it's not the user-specified position, get the difference in positions and try moving the window that amount. Also, does anybody have any ideas how I get Gnome working on my Red Hat system again? John F. Fay joh...@eg... "It is a poverty to decide that an unborn child must die in order that you may live as you like." - Mother Teresa |
From: Nuno A. <hun...@ne...> - 2003-03-13 21:13:31
|
On Thu, 2003-03-13 at 20:58, Fay John F Contr AAC/WMG wrote: > I think I got my Linux machine to run KDE instead of Gnome and I am > getting the same shift in the window position. So that's both Gnome > and KDE. > > If I may propose a fix, how about this: > - Create the window at the user-specified position > - Query the position of the window > - If it's not the user-specified position, get the difference > in positions and try moving the window that amount. John the problem was what somebody already said here, looks like on some WM you can choose if the decorations count on where the window is placed, so i think it's better not touch that. The thing that makes a difference is when you ask for the window's X and Y, it should return always acording to the WM, i.e. if you create a window on (100, 100) it must return always (100,100) even if the "real window" area is moved to (106,120) because of the decorations. > Also, does anybody have any ideas how I get Gnome working on my Red > Hat system again? If you have a graphical login you simply choose from a menu. If you have a text login just do the following: mv ~/.xinitrc ~/.xinitrc-OLD echo exec gnome-session > .xinitrc then just do "startx" so start x! :-] >By the way, what sort of user interface would there be to create a >window without decorations? i didn't quite get what you where asking here.. Hope this helps, Nuno Afonso |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-03-13 22:15:28
|
First, thank you for the advice on how to get back into Gnome. I now once again have gnomes running around on my desktop <grin>. If anybody tells me that Linux is easier to use than Windows, I will ... well, I guess I will politely disagree unless he can give me counterexamples. I went to the code in "freeglut" that creates the window ("freeglut_window.c", line 425 or so) and that calculates the window position in "glutGet" ("freeglut_state.c", line 240 or so). After a couple of consultations from the "man" pages, I have the following. (1) Creating the window calls "XCreateWindow" and passes it arguments "x" and "y", which according to the man pages are the coordinates of the outside of the window. It also passes it "w" and "h", which are the width and height of the inside (drawable) part of the window, and an argument of zero for "border_width". The "border_width" is supposed to be the width of the window's border in pixels, but this seems not to be the case. (2) In "glutGet", there is first of all a call to "XGetWindowAttributes", which returns a structure. The first two elements in the structure are "x" and "y", which are the coordinates of the upper left hand corner of the drawable area relative to the corner of the outside of the window. The second two elements are "width" and "height", which are the size of the drawable area; there are no surprises there. The third element is the "border_width" which was set to zero when the window was created. The function then calls "XTranslateCoordinates", passing it the "border_width" attribute twice as the input x- and y-coordinates, and receiving as output those coordinates relative to the upper left-hand corner of the screen. These are the values that it returns to the calling application as the window x- and y-coordinates. I would like to do one of two things, and I submit them to the group for a choice. In the present situation, one convention (the outside of the window) is used to create the window and another convention (the drawable area) is used when getting the window position. I consider this intolerable even though GLUT does it this way. Here are the ways we can fix it: (a) When creating the window, we can call "XGetWindowAttributes" to get the x- and y-coordinates of the drawable area relative to the corner of the window. We can then call "XMoveWindow" to move the window so that the drawable area is at the position specified by the application. This is how Windows does it and is my preferred solution. (b) When getting the position of the window, we can subtract off the x- and y-coordinates of the drawable area from what is presently calculated and return to the application the position of the outside of the window. This is not my preferred solution. Do people have a preference of one over the other? John F. Fay joh...@eg... "It is a poverty to decide that an unborn child must die in order that you may live as you like." - Mother Teresa |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-03-14 14:18:50
|
This is starting to get ridiculous. I have tried implementing option (a) below and have found that the "x" and "y" attributes, which are properly set by the time "freeglut" is in "glutGet", have the values of the window position on the screen when we create the window in "fgOpenWindow". In other words, if I do the following: x = 150 ; y = 300 ; windowHandle = XCreateWindow ( fgDisplay.Display, ... x, y, ... ) XGetWindowAttributes ( fgDisplay.Display, windowHandle, &winAttributes ) ; then the "x" and "y" fields of "winAttributes" are 150 and 300. I have tried calling "XGetWindowAttributes" from the end of "fgOpenWindow" and it returns the same values. In "glutGet", however, there is a call to "XGetWindowAttributes" which returns 6 and 20 for the "x" and "y" fields. Does anybody know what is going on here? John F. Fay joh...@eg... "It is a poverty to decide that an unborn child must die in order that you may live as you like." - Mother Teresa -----Original Message----- From: Fay John F Contr AAC/WMG [mailto:joh...@eg...] Sent: Thursday, March 13, 2003 4:15 PM To: fre...@li... Subject: RE: [Freeglut-developer] Window Positions <snip> I would like to do one of two things, and I submit them to the group for a choice. In the present situation, one convention (the outside of the window) is used to create the window and another convention (the drawable area) is used when getting the window position. I consider this intolerable even though GLUT does it this way. Here are the ways we can fix it: (a) When creating the window, we can call "XGetWindowAttributes" to get the x- and y-coordinates of the drawable area relative to the corner of the window. We can then call "XMoveWindow" to move the window so that the drawable area is at the position specified by the application. This is how Windows does it and is my preferred solution. (b) When getting the position of the window, we can subtract off the x- and y-coordinates of the drawable area from what is presently calculated and return to the application the position of the outside of the window. This is not my preferred solution. Do people have a preference of one over the other? John F. Fay joh...@eg... "It is a poverty to decide that an unborn child must die in order that you may live as you like." - Mother Teresa |
From: Nuno A. <hun...@ne...> - 2003-03-14 16:01:13
|
> x = 150 ; y = 300 ; > windowHandle = XCreateWindow ( fgDisplay.Display, ... x, y, ... ) > XGetWindowAttributes ( fgDisplay.Display, windowHandle, &winAttributes > ) ; > > then the "x" and "y" fields of "winAttributes" are 150 and 300. I > have tried calling "XGetWindowAttributes" from the end of > "fgOpenWindow" and it returns the same values. In "glutGet", however, > there is a call to "XGetWindowAttributes" which returns 6 and 20 for > the "x" and "y" fields. > > Does anybody know what is going on here? Has anyone thought that maybe the problem isn't freeglut/glut? I think the window managers are the problem. This is only an idea please correct me if i'm wrong.. I made a test on my window manager (fluxbox) and when i create a window on (0,0), the drawable window is really (0,0) (i.e. the decorations are out of the screen). So here's what i think, i don't really know how the window managers work, they must mapp the window when it is created into another window, so WM like Gnome must make "their" window (the window with decorations) start where the user specified ( (0,0) in this case), moving the drawable area to (0,0) + (x_offset, y_offset), this way, when you ask for the X and Y of your window the X servers returns (0+x_offset,0+y_offset). Any comments? Nuno Afonso |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-03-14 18:21:08
|
Now _that_ is a can of worms! What happens with other flavors of Linux? John F. Fay joh...@eg... "It is a poverty to decide that an unborn child must die in order that you may live as you like." - Mother Teresa -----Original Message----- From: Nuno Afonso [mailto:hun...@ne...] Sent: Friday, March 14, 2003 10:00 AM To: fre...@li... Subject: RE: [Freeglut-developer] Window Positions <snip> Has anyone thought that maybe the problem isn't freeglut/glut? I think the window managers are the problem. This is only an idea please correct me if i'm wrong.. I made a test on my window manager (fluxbox) and when i create a window on (0,0), the drawable window is really (0,0) (i.e. the decorations are out of the screen). <snip> |
From: Nuno A. <hun...@ne...> - 2003-03-14 19:14:41
|
On Fri, 2003-03-14 at 18:20, Fay John F Contr AAC/WMG wrote: > Now _that_ is a can of worms! What happens with other flavors of > Linux? Well to end this i simply tried the other window managers that i have (Openbox, Blackbox, Waimea and Twm) and all on all of them the decoration count, meaning that the window created on (0,0) had the decorations ON screen, even on Twm that SUCKS alot! The only one so far that creates with the decorations offscreen is Fluxbox.. So i think that we should let it create the windows where the decorations start (i.e. creating on (100, 100) show the drawing area on (106,120) on John case).. This actually makes some sense, because to the user of freeglut he gives the window position expecting the window to appear on that point (the window, not the drawable area..). So what you can do is either ignore this "feature" and let it return a "wrong" (x,y) or when you ask for the (x,y) of the window it returns (x - width_decorations, y - height_decoration) which would make you save another 2 variables (the witdh/height_decoration), and might be a bad thing.. You see, some window managers (like Gnome) aren't window managers, they are "desktop", i.e. they use an window manager to deal with the windows.. and you can switch from window manager while runing Gnome.. i'll try to explain it better: lets say you are using a window manager that has 6 of decorations width and 20 of decorations height, and you create a window on (100,100), so freeglut sees it's being displayed on (106,120) and saves the width and height of decorations as being (6,20), so whenever you ask for the window's X and Y it returns the position minus the (6,20). The problem comes if the user changes to someother window manager that has a different decoration size, e.g. (0,14), and when you asked for the window's X and Y it would return the position minus (6,20). This is an extreme situation... but it could happen. Nuno Afonso |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-03-14 18:57:23
|
I have a bit of data on the window managers on my own (Red Hat) system. There are three window managers available: Gnome, KDE, and "failsafe". "Failsafe" seems to be an extremely minimalist windowing system. It brings up windows without any decorations, and when I ask for something at position (20,20) I get the drawable area at (20,20). This is what "glutGet" returns as well. With no decorations, there really isn't any alternative. KDE and Gnome both behave in a similar fashion. When I ask for a window at position (20,20), I get a window whose outside decorations start at (20,20) and whose drawable area starts at (26,40). When I call "glutGet" to ask for the window position I get (26,40). KDE and Gnome differ in the size of the initial window. I asked for a window of 30x30 pixels. Gnome gave me what I asked for; KDE gave me a window 78 pixels wide and 30 pixels high. This was the case for three different windows, with three different titles. I find that the width for KDE is 78 pixels if I vary the height and desired width as well. Gnome gave me the desired size every time. I have a fourth entry in the Window Manager list called "Default." It looks and behaves just like KDE, so it probably is. What happens with other people's systems? John F. Fay joh...@eg... "It is a poverty to decide that an unborn child must die in order that you may live as you like." - Mother Teresa |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-03-14 19:43:29
|
There is a bright spot here, or at least I think there is. In "glutGet" the call to "XGetWindowAttributes" returns, among other things, the offset from the corner of the window to the corner of the drawable area. So we shouldn't have to save two additional variables and we shouldn't have to fix our offsets at (6,20). In theory at least, we should be able to subtract the "winAttributes.x" and "winAttributes.y" from the present "x" and "y" values and return to the user the position of the decoration. This is my option (b) from yesterday, the one I do not prefer but which would be acceptable. John F. Fay joh...@eg... "It is a poverty to decide that an unborn child must die in order that you may live as you like." - Mother Teresa -----Original Message----- From: Nuno Afonso [mailto:hun...@ne...] Sent: Friday, March 14, 2003 1:14 PM To: fre...@li... Subject: RE: [Freeglut-developer] Window Positions <snip> So what you can do is either ignore this "feature" and let it return a "wrong" (x,y) or when you ask for the (x,y) of the window it returns (x - width_decorations, y - height_decoration) which would make you save another 2 variables (the witdh/height_decoration), and might be a bad thing.. You see, some window managers (like Gnome) aren't window managers, they are "desktop", i.e. they use an window manager to deal with the windows.. and you can switch from window manager while runing Gnome.. i'll try to explain it better: lets say you are using a window manager that has 6 of decorations width and 20 of decorations height, and you create a window on (100,100), so freeglut sees it's being displayed on (106,120) and saves the width and height of decorations as being (6,20), so whenever you ask for the window's X and Y it returns the position minus the (6,20). The problem comes if the user changes to someother window manager that has a different decoration size, e.g. (0,14), and when you asked for the window's X and Y it would return the position minus (6,20). <snip> |
From: <hun...@ne...> - 2003-03-14 20:57:00
|
>There is a bright spot here, or at least I think there is. In = "glutGet" >the call to "XGetWindowAttributes" returns, among other things, the >offset from the corner of the window to the corner of the drawable = area. >So we shouldn't have to save two additional variables and we shouldn't >have to fix our offsets at (6,20). In theory at least, we should be >able to subtract the "winAttributes.x" and "winAttributes.y" from the >present "x" and "y" values and return to the user the position of the >decoration. This is my option (b) from yesterday, the one I do not >prefer but which would be acceptable. Why don't you like this option? From the users perspective i think it = makes=20 sense.. An option to create a window with the drawable area on the exact point you call the function would be adding a function (or adding flags = to=20 the function) to create a window without decorations. I think something like this is more important than some options that are on the page, like = a window=20 closing confirmation box. Nuno Afonso |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-03-14 22:18:23
|
Well, I guess I am showing a bias towards the behaviour of GLUT and "freeglut" under Windows because that is what I am most used to. Also, if we make the window position that of the decorations, we will have to change both "glutGet" in Linux and everything (both the create and the "glutGet" behaviour) in Windows. But I can certainly live with doing this. John F. Fay joh...@eg... "It is a poverty to decide that an unborn child must die in order that you may live as you like." - Mother Teresa -----Original Message----- From: hun...@ne... [mailto:hun...@ne...] Sent: Friday, March 14, 2003 2:55 PM To: fre...@li... Subject: RE: [Freeglut-developer] Window Positions >There is a bright spot here, or at least I think there is. In "glutGet" >the call to "XGetWindowAttributes" returns, among other things, the >offset from the corner of the window to the corner of the drawable area. >So we shouldn't have to save two additional variables and we shouldn't >have to fix our offsets at (6,20). In theory at least, we should be >able to subtract the "winAttributes.x" and "winAttributes.y" from the >present "x" and "y" values and return to the user the position of the >decoration. This is my option (b) from yesterday, the one I do not >prefer but which would be acceptable. Why don't you like this option? From the users perspective i think it makes sense.. An option to create a window with the drawable area on the exact point you call the function would be adding a function (or adding flags to the function) to create a window without decorations. I think something like this is more important than some options that are on the page, like a window closing confirmation box. Nuno Afonso ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: <hun...@ne...> - 2003-03-14 22:55:37
|
Well, i'm just a simple user of freeglut, either way you (developers) = choose will be ok for me.. The better thing was making it as alike as = possible on both Linux and Windows. This way there aren't some = inconsistences like java swing on Linux and Windows. Afonso |
From: Stephen J B. <sj...@li...> - 2003-03-12 20:38:14
|
On Wed, 12 Mar 2003, Fay John F Contr AAC/WMG wrote: > On Windows, GLUT does the same thing as it does on Linux while "freeglut" > gives me a window that is 30 pixels high by 104 pixels wide. The 104-pixel > width seems to be a minimum from Windows; if I ask for the window's width > immediately after creating it the value is 104 pixels. If I click on the > corner of the window and try to shrink its width I can't get it any > narrower. And if I click on the corner of a GLUT window, the width > immediately pops out to 104 pixels and will not get any less than that > value. Hmmm - that probably also depends on the length of the "Title" string. I guess Windoze doesn't like to truncate it. > I also found, by the way, that if the mouse leaves a "freeglut" window under > Windows its coordinates as passed to the keyboard callback immediately > freeze. Under Linux, and with both operating systems under GLUT, the > coordinates continue to change and take negative values or values greater > than the window size. This also bears looking into. That's certainly the desired (and expected) behaviour. You need to be able to click on something and drag it off the edge of a window (for example) - and negative mouse coords are to be expected. Once again, I have no idea what you have to do under Windoze. ---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |