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

[Richard Frith-Macdonald]

Follow-up Comment #21, bug #17377 (project gnustep):

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. 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?17377>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/