Re: Geometry problem

[Jeff Teunissen]

Kazunobu Kuriyama wrote:

> I greatly appreciate your educational e-mail. In particular,
> I believe the first half of the mail should be on a GNUstep tutorial
> (especially for those who are familiar with Xlib and other GUI toolkits
> which use freefall coordinates system.).

Thanks. I try. :)

> I have a few points to make sure. I would be deadly happy if you
> could find time to reply to them.

I'll do my best. See below.

> Jeff Teunissen wrote:
> 
>   >>If Object A is a parent or ancestor of Object B (in a sense of
>   >>window hierarchy), the answer may be easy.  I have no idea,
>   >>however, if Object A is an instance of NSApplication.
>   >>
>   >
>   >It's not, it's probably an instance of NSView (or one of its
>   > subclasses).
> 
> Then, doesn't the top of the NSView tree play a special role like the
> so-called shell widgets of Xt?

No, not really.

*Any* view can be the content view of a window. all you have to do is:

[aWindow setContentView: myView];

and myView will become aWindow's content view (though it will have its
frame changed to match the content area of the window). There's nothing
special about the "top level NSView", it's just that all windows must have
one, and only one (that view can have subviews of course), content view.

>   >Every view has its own coordinate system. Every window has a "content
>   >view", which takes up its entire displayable area (the window's
>   >border, etc. are owned by the window system/window manager and are,
>   >of course, not part of this displayable area).
> 
> Does a 'window' simply mean a rectangular entity on a display's screen,
> or an instance different from a view instance?

An NSWindow object represents the rectangular area, and has methods for
setting the position, size, etc. of the window.

>   >Note: coordinates are floating-point, and a coordinate system may be
>   >modified, scaled, rotated, repositioned, etc. arbitrarily.
> 
> As such, we often need to round a floating-point to an integer.  Is
> there a standard macro/inline function in the GNUstep libraries for this
> purpose? Or is it left to programmer's preference?

I believe that the usual C methods are used. So I suppose it is indeed
"left to the programmer's preference". The difference here is that there's
generally no real connection (at least, there's not supposed to be)
between pixels and coordinates/points, because they're intentionally
separated.

In NeXTstep/OPENSTEP, this was assisted by using "stroke adjust", with
which you would draw a line with a width of 0.0 points. When the Display
PostScript engine encountered such a line, it would do its best to align
the line on a pixel boundary, and draw it exactly one pixel wide.

This gave the result of a sharp-looking image, while allowing the display
resolution to be disconnected from the internal resolution of the
application.

At very high resolutions (300 ppi, for example) this is somewhat less
desirable, because a 1-pixel line at 300 pixels per inch is very thin
indeed. :)

>   >You could create an unflipped view such that the origin is at the top
>   >right (by translating the origin and rotating the coordinate system
>   >180 degrees, which will cause the contents to be upside-down and
>   >backwards; or just by setting the bounds origin and using negative
>   >coordinates), or even at the center of the view (by setting the
>   >bounds origin). In this case, negative coordinates are valid (they're
>   >already valid anyway, just clipped to the view's visible bounds).
>   >This can make things interesting, as you can probably imagine. :)
> 
> Then, I'm wondering if the region of a window that should be retained
> when the window is resized (the so-called gravity in Xlib), changes
> depending on a coordinates system I choose.

The window has no "contents", other than its content view. The part of the
view that is visible is retained (if the window is told to retain or
buffer its backing store, as is usual -- this avoids expose events, to use
the X terminology, which cause the views to redraw themselves). The
coordinate system in use does not really come into the equation.

[snip code example]

> Thank you very much for sharing your precious time with me.

No problem.

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/