[bug #17377] Various frame related methods in NSWindow return wrong results

[Quentin Mathé]

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/