bugGNUstep - Bugs: bug #17377, Various frame related methods in...

Group
 
 

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

Submitter:  Quentin Mathé <qmathe>
Submitted:  Tue 08 Aug 2006 09:41:37 PM UTC
   
 
Category:  Gui/AppKit Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  CaS
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 19 Feb 2007 05:07:22 PM UTC, comment #23: 

Closed as there was no further comment after Richards change.

Fred Kiefer <FredKiefer>
Group Member
Tue 12 Sep 2006 02:54:12 PM UTC, comment #22: 

I believe this is now fixed in gui and for the xlib and art backends.
I've just comitted some changes for flushing data to screen and everything seems to be working correctly for them now.
All passing of coordinates between frontend and backend should now use the frontend (OpenStep) coordinates.
The window and screen coordinates should be consistent irrespective of whether the gui or the backend decorates the window, and should behave as with MacOS-X
The top level decoration view in the window should fill the whole window frame irrespective of whether it is handling window decorations or not.
I imagine all the other backends will need adjustment too ... not sure about the xdps backend though ... are we still maintaining it?

Richard Frith-Macdonald <CaS>
Group Member
Sun 10 Sep 2006 04:36:34 PM UTC, comment #21: 

Well, I consider the current code in SVN a partial fix.

It's all fine for the case where the gui handles window decorations and the backend X window is the same size as the openstep window ... but for the other case where the window manager handles window decorations we still have problems ...

I have corrected long-standing bugs in the X backend which resulted in incorrect calculation of the offsets between the position of the parent window providing decorations and the windows we draw on.

I have corrected the methods in the gui which pass window and content view frames to use the correct values, and changed the X backend to map these corrected frame to/from the appropriate X coordinates.

However ... that's by no means a complete solution.

The decoration view in the gui is still the size of the backend X window ... this is wrong  as it means that the conversion from view coordinates to/from the window base coordinates is incorrect where a window has borders of any sort.

Mostly this does not show up because the X backend is putting incorrect coordinates into the NSEvent objects it generates ... it takes the coordinates from the x window and flips them ... which gives coordinates for the content view ... ie matching the error in the view<->window coordinates.

Since the window frame corrdinates are now correct, there is a discrepancy wherever code deals with positioning of windows (using correct coordinates) using the incorrect mouse position information from NSEvent objects, or when it tries to postion a window based on the location of something drawn inside another window (since the mapping from the drawn coordinate to screen coordinates is wrong).

The way to fix this is to correct the backend to put the right values in the NSEvent objects, and fix the gui to make the top level window view a rectangle filling the entire window frame so that the current code for mapping from view to window base coordinates works.

The problem with that (I've tried it on my local machine), is that it then means that all drawing in the content rect is offset from the origina in the top level view (because of the left and bottom borders of the window frame) ... and the backend code is assuming that the coordinates it is being told to draw in can be simply mapped to X window coordinates by a simple flip.  I tried a quick hack to compensate for that, changing the transformation matrices used by drawing functions to put in the offset so that drawing in the gui should provide the coordinates expected by the backed, but found that various glitches show that not all drawing seems to use the matrices (presumably various bugs in parts of the drawing code).

So, perhaps the cleanest solution would be to use OpenStep coordinates throughout the gui and for the gui/backend interface, and have the backend perform all necessary transformations.  I'm not sure about this though ... if we want writing backend code to be easy, perhaps we should do all the transformation stuff in the gui.  I guess we could pass all window and mouse positioning using OpenStep coordinates, and all drawing within a window using the coordinates of the top level view.  The inconsistency of that is inelegant though.

Richard Frith-Macdonald <CaS>
Group Member
Sat 09 Sep 2006 08:42:38 PM UTC, comment #20: 

Just confirm that everything looks fine now after a reinstallation of GNUstep SVN version. Popup menu and drag-and-drop behave as expected. Test with Azalea and Metacity.

-Deleted Account- <yjchen>
Fri 08 Sep 2006 02:35:25 AM UTC, comment #19: 

Confirmed in Gorm.

Gregory John Casamento <gcasa>
Group administrator
Thu 07 Sep 2006 01:13:54 PM UTC, comment #18: 

If a view is in a window with a title bar, it gets dragging events not in its frame but in a rect that is shifted down by about the size of the tile bar.
This is visible in GWorkspace, in GNUMail moving a message in another mailbox and in Gorm dragging a new object in a window.

This is valid also for NSDraggingSource; using -dragImage:at:offset:event:pasteboard:source:slideBack:, if the image is not deposited and slides back, its destination will be shifted down by the same value.

Enrico Sersale <esersale>
Group Member
Thu 07 Sep 2006 02:21:29 AM UTC, comment #17: 

Okay, found one minor issue.   When opening a pop up buttons, the menu items are not aligned with the button's position in the window.  The appear somewhat below the button position.

Please see the attached "prefs_popup.jpg" file.

Gregory John Casamento <gcasa>
Group administrator
Thu 07 Sep 2006 02:07:39 AM UTC, comment #16: 

After recent changes, this seems to work perfectly. :)  The frames look the same with both X11 and GS drawing the decorations.  

Sorry for the terse description earlier, I was leaving, but noticed a problem, so I just wrote it down so that you would know there was an issue.

I will test further, but so far it's good. :)

GJC

Gregory John Casamento <gcasa>
Group administrator
Wed 06 Sep 2006 11:15:38 PM UTC, comment #15: 


> Just attach a screenshot. The left side is Gorm, which looks normal. The
> right side is GWorkspace, which has the black shadow.


I can only confirm that all the applications, Gorm included, have the black space. This with WindowMaker-0.92 and the latest SVN on a system just reinstalled after the last release of -base and -gui.
P.S. I've written neither NSOpenPanel nor NSRunAlertPanel() and GWorkspace doesn't anything special with them.

Enrico Sersale <esersale>
Group Member
Wed 06 Sep 2006 10:30:48 PM UTC, comment #14: 

Just attach a screenshot. The left side is Gorm, which looks normal. The right side is GWorkspace, which has the black shadow.

-Deleted Account- <yjchen>
Wed 06 Sep 2006 09:53:11 PM UTC, comment #13: 

Here ALL the apps have the black space between the title bar and the contents.

Enrico Sersale <esersale>
Group Member
Wed 06 Sep 2006 07:25:22 PM UTC, comment #12: 

On Metacity (Gnome) and Azalea, the Ink and Gorm work fine.
In GWorkspace, the content view of NSWindow is shifted
and a black space is left. Even the standard NSAlertPanel
in GWorkspace has this problem, but not in Gorm.
But menu looks fine.
Not sure it is caused by the fix, though.
No other obvious problems (window drifting, etc.) so far.

-Deleted Account- <yjchen>
Wed 06 Sep 2006 01:59:39 PM UTC, comment #11: 

I made a small fix to setting hints ... seems to correct problem with frame growing (though I'd like to understand why it works).
Other than that, I'm not sure what problem you are seeing ... I don't know what either jpeg is expected to look like, so I don't know what 'The frames seem off, more than before' really means.  Maybe I've corrected your issue, but maybe not.

Please could you check again, and if a problem remains, let me know more exactly what the problem is and how it can be reproduced.

Richard Frith-Macdonald <CaS>
Group Member
Wed 06 Sep 2006 01:32:35 PM UTC, comment #10: 

Something seems odd with this fix.... please see the attached pics.

The frames seem off, more than before.    One of them is with X11 decorations, the other is with GS decorations.

GJC

Gregory John Casamento <gcasa>
Group administrator
Wed 06 Sep 2006 11:48:51 AM UTC, comment #9: 

I have reworked a lot of the frame handling code in the gui to correct the methods mapping between frame and content rect (as well as a few others) and to remove the extra methods which had been introduced to provide the functionality that the standard methods should have provided.

I've also reworked most of the frame/offfset handling code in the X backend so that it should work properly to pass OpenStep frames between it and the gui library (mostly a case of getting the offsets between the OpenStep frame and the X window frame right).  I tested this with WindoMaker, but most of the fixes I made should apply to other window managers too.

The changes are now in SVN.

Richard Frith-Macdonald <CaS>
Group Member
Mon 04 Sep 2006 03:04:53 PM UTC, comment #8: 

Is anyone working on this?

It seems to me that the _frame ivar should be fixed to contain the proper window frame (ie the rectangle occupied by the entire window incuding decorations) on the screen.  Currently the _frame ivar varies depending on whether the gui is decorating the window or not ... which (even though it's a private ivar) is IMO a bad thing.

All public methods passing around a window frame should use this frame value.  Currently the frame passed varies depending on whether the gui is decorating the window or not ... a very, very bad thing.

The window decoration view should be the same size as the window frame if the gui is handling decorations, and the same size as the content view if the backend (window manager) is handling decorations.

Reworking the gui and backend code to fix the current situation is probably fairly tricky and can't really be done gradually :-(

Richard Frith-Macdonald <CaS>
Group Member
Wed 16 Aug 2006 09:50:11 AM UTC, comment #7: 

In my previous entry, I wrote incorrect statements about frameRect and contentRect, I thought windowFrame and frameRect were totally unrelated by reading the following method name.

/*
Internal helpers.

Returns the internal window frame rect for a given (screen) frame.
*/
+(NSRect) windowFrameRectForFrameRect: (NSRect)aRect
    styleMask: (unsigned int)aStyle
{
  aRect.origin = NSZeroPoint;
  return aRect;
}

windowFrame is basically just the frameRect with a zero origin. Is this just the same as the bounds rectangle returned by [window bounds]?

So… Here is a corrected version of my summary:

- screenRect == frameRect on Cocoa/OpenStep
- contentRect == contentRect on Cocoa/OpenStep
- frameRect (windowFrame with a non zero origin) == frameRect or contentRect on Cocoa/OpenStep (since it represents the frame manipulated in the backend)

In other words, the frameRect returned by [window frame] can be equal to either screenRect (when GSX11HandlesWindowDecorations=NO) or contentRect (when GSX11HandlesWindowDecorations=YES)

Hopes I haven't done any new misunderstandings,
Quentin.

Quentin Mathé <qmathe>
Group Member
Wed 16 Aug 2006 09:07:37 AM UTC, comment #6: 

I finally found Alexander's documentation in NSWindow.h:

  /*
  A window really has three interesting frames:
 
  The screen frame. This is the frame of the entire window on the screen,
  including all decorations and borders (regardless of where they come from).
  (On X, we can only guess what the screen frame is.)

  The window frame. This is the frame of the backend window for this window,
  and is thus the base of the coordinate system for the window. IOW, it's
  the frame of the area we can draw into.

  The contect rect. This is the frame of the content view.

  Wrt. size, ScreenFrame >= WindowFrame >= ContentRect. When -gui doesn't
  manage the window decorations, WindowFrame == ContentRect. When -gui does
  manage the window decorations, WindowFrame will include the decorations,
  and ScreenFrame == WindowFrame.


  To get coordinate transforms and stuff right wrt. OpenStep, we really want
  the window frame here.

  For hysterical reasons, _frame used to be the screen frame. However, the
  resulting inconsistencies caused a bunch of problems. Thus, _frame is the
  window frame. The other rectangles/sizes passed around in NSWindow
  methods are supposed to all be window frames.
  */

The last paragraph makes sense at implementation level, but not at API level since it breaks OpenStep/Cocoa compatibility and prevents precise layout of the windows on screen.

To summarize:

frameRect is returned by [window frame]
contentRect is returned by [[window contentView] frame] (not sure this returns the proper value on GNUstep)

- screenRect == frameRect on Cocoa/OpenStep
- frameRect == contentRect on Cocoa/OpenStep
- windowFrame == frameRect or contentRect (since it represents the frame manipulated in the backend)

windowFrame is a specially confusing term taking in account it can be either screenRect or contentRect. I found screenRect quite confusing to since there is an NSScreen class in AppKit.

Quentin.

Quentin Mathé <qmathe>
Group Member
Fri 11 Aug 2006 12:37:22 PM UTC, comment #5: 

The code we have there in the different decorators is there on purpose. When Alexander Malmberg implemented the window decoration handling inside of GNUstep gui he wanted to end up with things right the way they are now.
I remember there was documentation for all of this, but I cannot find it at the momenet. The main thing was that Alex came up with three rectangles where OpenStep only has two, contentRect and frameRect. The third one being screenRect, which is the actual space on the screen occupied by the window. Including the window decoration, from what ever source it is coming. For the different decorators two of these three rectangles are identical, but different ones for the different decorators.
I would think that you should get the values you are aiming for by using the screenRect methods instead of the frameRect methods. But this would make your code incompatible to code for Cocoa or OpenStep.
As far as I can tell this screenRect code does not get used anywhere. Perhaps it would be better to reconsider the whole interface.

Fred Kiefer <FredKiefer>
Group Member
Thu 10 Aug 2006 12:51:08 AM UTC, comment #4: 

When GNUstep draws its own decorations (GSX11HandlesWindowDecorations=NO), these methods work properly.  The problem comes, as you pointed out when GNUstep DOESN'T draw the decorations (GSX11HandlesWindowDecorations=YES) and it is left up to the window manager.

Under Cocoa (or OpenStep) the entire window frame, including decorations (window bar, widgets and all on top and bottom) are considered part of the window frame.   So this means that, since GNUstep knows how big it's widgets are, it can easily get the window frame size.

When GNUstep doesn't draw it's widgets it uses assumes that the window frame is the same as the content frame, which isn't correct.  To correct this issue, it will be necessary to include the window top-bar and the other widgets on the bottom into the size of the window to get it right.

Hope this helps...

GJC

Gregory John Casamento <gcasa>
Group administrator
Wed 09 Aug 2006 10:17:43 PM UTC, comment #3: 

I think I have found where the bug is located at least when backend decorations are used.

In GSWindowDecorationView.m, there are the two following methods called by their NSWindow counterparts.

+ (NSRect) contentRectForFrameRect: (NSRect)aRect
styleMask: (unsigned int)aStyle
{
  float t, b, l, r;

  [self offsets: &l : &r : &t : &b
   forStyleMask: aStyle];
  aRect.size.width -= l + r;
  aRect.size.height -= t + b;
  aRect.origin.x += l;
  aRect.origin.y += b;
  return aRect;
}

+ (NSRect) frameRectForContentRect: (NSRect)aRect
styleMask: (unsigned int)aStyle
{
  float t, b, l, r;

  [self offsets: &l : &r : &t : &b
   forStyleMask: aStyle];
  aRect.size.width += l + r;
  aRect.size.height += t + b;
  aRect.origin.x -= l;
  aRect.origin.y -= b;
  return aRect;
}

As we can see above, the important method is -offset::::forStyleMask:

In GSBackendWindowDecorationView (code pasted below), this method -offset::::forStyleMask: is overriden with a dummy implementation instead of calling the method similarly named in -back.
This is curious, but the next method -screenOffsets::::forStyleMask: seems to be precisely doing this.


@implementation GSBackendWindowDecorationView

+(void) offsets: (float )l : (float )r : (float )t : (float )b
   forStyleMask: (unsigned int)style
{
  *l = *r = *t = *b = 0.0;
}

+(void) screenOffsets: (float )l : (float )r : (float )t : (float )b
   forStyleMask: (unsigned int)style
{
  [GSCurrentServer() styleoffsets: l : r : t : b : style];
}

+(NSRect) windowFrameRectForFrameRect: (NSRect)aRect
    styleMask: (unsigned int)aStyle
{
  float l, r, t, b;
  [self offsets: &l : &r : &t : &b forStyleMask: aStyle];
  aRect.size.width -= l + r;
  aRect.size.height -= t + b;
  return aRect;
}

/*
Returns the content rect for a given window frame.
*/
+(NSRect) contentRectForWindowFrameRect: (NSRect)aRect
      styleMask: (unsigned int)aStyle
{
  return aRect;
}

@end

I have to state that I don't understand the purpose of all these 'screen' prefixed methods in GSWindowDecorationView.m.
Finally other methods like windowFrameRectForFrameRect:styleMask:, -contentRectForWindowFrameRect:styleMask:, -screenRectForFrameRect:styleMask: etc. makes no sense at first sight.
Any ideas ?

For example, -frameRectForContentRect:styleMask: is identical to -screenRectForFrameRect:styleMask:... Well not exactly since the latter looks like the correct method to use when backend decorations are turned on if you want to compute the window frame rect from its content view rect (the normal role of the former).

+ (NSRect) frameRectForContentRect: (NSRect)aRect
styleMask: (unsigned int)aStyle
{
  float t, b, l, r;

  [self offsets: &l : &r : &t : &b
   forStyleMask: aStyle];
  aRect.size.width += l + r;
  aRect.size.height += t + b;
  aRect.origin.x -= l;
  aRect.origin.y -= b;
  return aRect;
}

+ (NSRect) screenRectForFrameRect: (NSRect)aRect
styleMask: (unsigned int)aStyle
{
  float t, b, l, r;

  [self screenOffsets: &l : &r : &t : &b
forStyleMask: aStyle];
  aRect.size.width += l + r;
  aRect.size.height += t + b;
  aRect.origin.x -= l;
  aRect.origin.y -= b;
  return aRect;
}

I think there are perhaps similar issues in GSStandardDecorationView leading to incorrect window border/titlebar size computation.

Quentin.

Quentin Mathé <qmathe>
Group Member
Wed 09 Aug 2006 09:27:35 PM UTC, comment #2: 

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.

Quentin Mathé <qmathe>
Group Member
Wed 09 Aug 2006 03:41:48 PM UTC, comment #1: 

Just to make sure I understand this correctly, would you say the the GNUstep behaviour for the case GSX11HandlesWindowDecorations=YES is totally correct? If not, which problem did I overlook for this case?
For the case GSX11HandlesWindowDecorations=NO we cannot expect the frame of the content view to start at 0, but the border should, as always start at 0.
What is questionable are the values returned by frameRectForContentRect: and contentRectForFrameRect: I will have to look into the documenation for this methods to see if the returned values are incorrect.
Could you please explain, where the current GNUstep behaviour is causing you problems? Perhaps these could be worked around on a different level.

Fred Kiefer <FredKiefer>
Group Member
Tue 08 Aug 2006 09:41:37 PM UTC, original submission:  

Fresh GNUstep core install from today svn repository on Linux x86 Ubuntu.

Hi,

I have discovered the following methods
+frameRectForContentRect:styleMask:
+contentRectForFrameRect:styleMask:
return bogus results with NSWindowTitledMask at least.

I built a test application (in attachment) to show the issues. I think there are related to several bugs in frame handling. The first one follows from the fact [[window contentView] frame] should probably return a rect with the origin equal to zero (this is Cocoa behavior). The second one is surely related to wrong frame computations and/or wrongly implemented methods in GSWindowDecorationView.m GSStandardWindowDecorationView.m.

Below are the results of my test application on both GNUstep (with and without backend decorations) and Cocoa…

Output with GNUstep and GSX11HandlesWindowDecorations=NO:

2006-08-08 20:14:35.809 TestWindowFrame[32679] Window frame {x = 221; y = 488; width = 602; height = 432}
2006-08-08 20:14:35.809 TestWindowFrame[32679] Window content rect {x = 1; y = 9; width = 600; height = 400}
2006-08-08 20:14:35.810 TestWindowFrame[32679] +frameRectForContentRect: result is {x = 0; y = 8; width = 602; height = 424}
2006-08-08 20:14:35.810 TestWindowFrame[32679] +contentRectForFrameRect: result is {x = 222; y = 489; width = 600; height = 408}
2006-08-08 20:14:36.517 TestWindowFrame[32679] File NSView.m: 413. In [GSStandardWindowDecorationView -initWithFrame:] given negative width
2006-08-08 20:14:36.517 TestWindowFrame[32679] File NSView.m: 418. In [GSStandardWindowDecorationView -initWithFrame:] given negative height
2006-08-08 20:14:36.517 TestWindowFrame[32679] File NSView.m: 413. In [NSView -initWithFrame:] given negative width
2006-08-08 20:14:36.518 TestWindowFrame[32679] File NSView.m: 418. In [NSView -initWithFrame:] given negative height
2006-08-08 20:14:36.518 TestWindowFrame[32679] File NSView.m: 1018. In [NSView -setFrame:] given negative width
2006-08-08 20:14:36.518 TestWindowFrame[32679] File NSView.m: 1023. In [NSView -setFrame:] given negative height
2006-08-08 20:14:36.520 TestWindowFrame[32679] File NSView.m: 1018. In [GSStandardWindowDecorationView -setFrame:] given negative width
2006-08-08 20:14:36.520 TestWindowFrame[32679] File NSView.m: 1023. In [GSStandardWindowDecorationView -setFrame:] given negative height

Output with GNUstep and GSX11HandlesWindowDecorations=YES:

2006-08-08 20:32:46.816 TestWindowFrame[760] Window frame {x = 221; y = 520; width = 600; height = 400}
2006-08-08 20:32:46.817 TestWindowFrame[760] Window content rect {x = 0; y = 0; width = 600; height = 400}
2006-08-08 20:32:46.817 TestWindowFrame[760] +frameRectForContentRect: result is {x = 0; y = 0; width = 600; height = 400 }
2006-08-08 20:32:46.817 TestWindowFrame[760] +contentRectForFrameRect: result is {x = 221; y = 520; width = 600; height =  400}

Output with Cocoa (the nib file is different then size and origin of the window too):

2006-08-08 20:27:24.875 TestWindowFrame[10060] Window frame {{220, 433}, {480, 382}}
2006-08-08 20:27:24.876 TestWindowFrame[10060] Window content rect {{0, 0}, {480, 360}}
2006-08-08 20:27:24.877 TestWindowFrame[10060] +frameRectForContentRect: result is {{0, 0}, {480, 382}}
2006-08-08 20:27:24.877 TestWindowFrame[10060] +contentRectForFrameRect: result is {{220, 433}, {480, 360}}

Quentin.

Quentin Mathé <qmathe>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #10707:  prefs_popup.jpg added by gcasa (24KiB - image/jpeg - Shows gorm preferences popup with the items slightly misaligned.)
file #10703:  GUI-bug.png added by yjchen (151KiB - image/png)
file #10700:  GSDecorations.jpg added by gcasa (354KiB - image/jpeg - GNUstep drawing the decorations)
file #10699:  X11Decorations.jpg added by gcasa (327KiB - image/jpeg - Showing Gorm with X11 drawing the decorations...)
file #10492:  TestWindowFrame.tar added by qmathe (30KiB - application/x-tar)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-02-19 FredKiefer StatusReady For Test Fixed
        Open/ClosedIn Test Closed
    2006-09-07 gcasa Open/ClosedOpen In Test
        Attached File- Added prefs_popup.jpg, #10707
    2006-09-06 yjchen Attached File- Added GUI-bug.png, #10703
    2006-09-06 gcasa Attached File- Added GSDecorations.jpg, #10700
    2006-09-06 gcasa Attached File- Added X11Decorations.jpg, #10699
    2006-09-06 CaS StatusIn Progress Ready For Test
    2006-09-05 CaS StatusNone In Progress
        Assigned toNone CaS
    2006-08-08 qmathe Attached File- Added TestWindowFrame.tar, #10492

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code