Follow-up Comment #2, bug #17377 (project gnustep): Hi Fred,
I have done more tests today. It's more complicated than what I thought initially. My output test results were done with Azalea (Etoile WM derived from OpenBox), it seems to have extra issues related to resize handling. So I decided to redo my tests with WindowMaker and Metacity since I observed issues with them also. Going to discuss results I got with Metacity now (they are mostly identical to the one I got with Azalea). It's important to note the frame rect is the frame of the window and the content rect the frame of the window content view (according to Cocoa documentation). The GNUstep behaviour for the case GSX11HandlesWindowDecorations=YES is wrong, because I +frameRectForContentRect: and +contentRectForFrameRect: results are incorrect, they look swapped : bizarrely the first one returns the content rect and the second one the frame rect. Moreover the frame and the content rect cannot have logically the same height. Output with GNUstep/Metacity and GSX11HandlesWindowDecorations=YES: 2006-08-09 21:11:57.146 TestWindowFrame[32045] Window frame {x = 222; y = 516; width = 600; height = 400} 2006-08-09 21:11:57.147 TestWindowFrame[32045] Window content rect {x = 0; y = 0; width = 600; height = 400} --> According to the two previous lines, the size of the frame rect is equal to the size of the content rect, this is obviously wrong since the window has a title bar. 2006-08-09 21:11:57.147 TestWindowFrame[32045] +frameRectForContentRect: result is {x = 0; y = 0; width = 600; height = 400} --> The result of this method should be the frame rect, but we just get a totally wrong origin (close to the one of the content rect), a wrong height, the width is correct though. 2006-08-09 21:11:57.147 TestWindowFrame[32045] +contentRectForFrameRect: result is {x = 222; y = 516; width = 600; height = 400} --> The result of this method should be the content rect, but we just get a totally wrong origin (close to the one of the frame), a wrong height, the width is correct again though. Output with GNUstep/Metacity and GSX11HandlesWindowDecorations=NO: 2006-08-09 21:03:33.668 TestWindowFrame[31834] Window frame {x = 222; y = 484; width = 602; height = 432} 2006-08-09 21:03:33.668 TestWindowFrame[31834] Window content rect {x = 1; y = 9; width = 600; height = 400} Everything looks fine now here. 2006-08-09 21:03:33.668 TestWindowFrame[31834] +frameRectForContentRect: result is {x = 0; y = 8; width = 602; height = 424} --> The result of this method should be the frame rect, but we just get a totally wrong origin (close to the one of the content rect), a wrong height, the width is correct though. 2006-08-09 21:03:33.669 TestWindowFrame[31834] +contentRectForFrameRect: result is {x = 223; y = 485; width = 600; height = 408} --> The result of this method should be the content rect, but we just get a totally wrong origin (close to the one of the frame), a wrong height, the width is correct again though. For the frame of the content view (aka content rect), you are right the frame origin doesn't have to be zero when you take in account the window can have a border. On Cocoa, I think the origin of the content rect is always zero because a window doesn't have a border at the bottom even when it isresizable (the resize corner is inside the window content view). The current GNUstep behaviour is causing me problems because you cannot obtain and set the frame of a window by computing its content view size. This is a very common operation when you want to resize the content view to fit perfectly a layout where a new view has just been inserted. For example : a preferences window or an inspector with panes where each pane is loaded and inserted on the fly (you have to compute the size of the window yourself). I have code to handle such resizing working flawlessly on Cocoa, but not really on GNUstep unless I tweak it to approximate the proper window frame. I have more to say about this, but this is already a lengthy reply. :-) I'm going to post an updated TestWindowFrame application soon. Thanks for your reply, Quentin. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=17377> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep