On 2 Mar 2007, at 14:08, Fred Kiefer wrote:
This mail is mainly for Richard, but others may have an idea here
as well.
In XGServerWindow there is the method windowdevice: that manages some
buffers and then tells the graphics context about the window. This
gets
done via a call to GSSetDevice() and the offset of the window is
passed
in. I have two issues with this offset. The simpler one is that I
think
the second value is the wrong way around. It is computed as
NSHeight(window->xframe) + b
but most likely it should be
NSHeight(window->xframe) - b
or just b
This has been taken care off in all backends, so it wont do any harm.
Still it looks wrong to me.
The other issue is worse, as it may result in wrong drawing. I
think the
offset here is needed for the case, where GNUstep and not the window
manager handles the window border. In that case all the drawing will
happen with a certain offset to the X window. When X handles the
window
decoration then the offset is of now relevance to the actual
drawing, as
we always draw in window coordinates. As far as I can see this method
now does the opposite of this. It sets the offset for the case when X
handles the window decoration in the other case it is 0, 0 (modulo the
above problem.
Now there may be some reason to this and the other backends seem to be
handling this correctly. I just ran into this with the cairo backend,
where there even is a cairo function to define device offset and
noticed
a problem.
I'm sure I don't clearly understand what you are saying ... but I
spent quite a while ensuring that coordinate mappings were working
consistently in all the backends, so I have a fair idea (subject to
the limitations of my rather poor memory) of what's going on.
We use the offsets in the gui to map between backend window
coordinates and gnustep window coordinates (and hence screen
coordinates in both backend and frontend), so it's critical that we
get them right or positioning of windows is messed up (that's why we
used to have problems with windows creeping across the screen and
popup button menus not lining up on top of the buttons). In
particular, the OpenStep/MacOS-X API requires that the base
coordinate system of the gnustep window *must* include the window
border/decorations, so this coordinate system is not the same as the
coordinate system of the content view of the window.
NB. where you say 'we always draw in window coordinates' it's
important to remember that this is true for gnustep/OpenStep/MacOS-X
window coordinates ... which means that, unless we are handling the
window decorations, it is NOT true for backend window coordinates
(even leaving aside the flipping issue).
When I did the fixes to the backend, I took the way the best behaving
backend was doing things, and got everything to work on that basis.
That may well not be the clearest solution (I guess that's what you
are talking about with the GSSetDevice() offsets.
If we are decorating a window ourselves then the offsets are zero and
the backend and gnustep window coordinates are the same (except for
flipping required because the vertical coordinates of the two systems
are the opposite way round).
But if the server/window-manager is handling window decorations then
the coordinates within the X window no longer map readily to gnustep
window coordinates. From the point of view of the gnustep window of
size w,h the drawable area is inset from the window rectangle, (l
bits from the left, r bits from the right, t bits from the top and b
bits from the bottom). This is currently the same rectangle as the
gnustep window's contentView (because the window manager is doing
decorations, the gui never draws outside the content view), but when
we do microsoft style menus in windows we will need the menu to be
drawn outside the content view but inside the drawable area of the
backend window.
Anyway, while we really want four values to describe offsets,
GSSetDevice() only provides two, so I guess the original code I based
changes on picked two fairly arbitrarily (probably whatever seemed
easiest at the time).
Now, when we want to draw a dot at x,y we need to subtract l and b
from the coordinates and then flip (because gnustep and X have
flipped vertical axes).
The horizontal coordinate is therefore x-l and the vertical is y-b
The drawable height is h-(t+b) so the vertical coordinate is h-(t+b)-
(y-b) or simply h-t-y
I think the offsets passed to GSSetDevice() were intended as a simple
translation to map from one coordinate system to the other, but that
plainly doesn't work and we end up with non-intuitive code ... where
the backends take the values used and employ them to construct the
correct mappings, but not in any clear way.
To my mind, if doing a cleanup of all this code, it would be clearest
if we passed the four inset values to GSSetDevice()
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
