[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trying to figure out the logic...

From: Thomas E. Dickey
Subject: Re: trying to figure out the logic...
Date: Fri, 9 May 2003 07:00:46 -0400 (EDT)

On Fri, 9 May 2003, D. Stimits wrote:

> This isn't a bug, but I'm perplexed in trying to figure out something in
> how ncurses is implemented (this is ncurses 5.3, redhat 7.3). I'm
> looking at the type SCREEN, and see it typedef'd to struct screen. I'm
> looking because I am trying to figure out how a SCREEN* can provide a
> WINDOW*. My discovery is that, recursively within /usr/include/, that

but it doesn't provide a WINDOW*.

a WINDOW tells ncurses what to display on the screen.
a SCREEN tells how it is doing that.

Historically, WINDOW's came first, and applications referred to its
members, e.g., the coordinates.  SCREEN was a refinement, and (with
hindsight), the developers probably realized that making a struct's
members visible was a drawback.  So it's always been opaque, afaik.

It would have been possible to do this for WINDOW as well, but it's
apparent that no one tried.  The macros used for accessing struct members
are not well-standardized or complete in X/Open's light editing of the
SVr4 curses - probably there's little motivation when the related code
doesn't have those hidden.  (NetBSD makes WINDOW opaque, but that makes it
harder to port code to it).

> struct screen is never prototyped. I even ran gcc with a -E to
> preprocess it and stop, the output never gave the prototype of struct
> screen, only the alias with typedef struct screen SCREEN. Being that it
> always uses only a pointer to the SCREEN, perhaps it only needs to know
> the size of a pointer, and thus the actual knowledge of struct screen is
> not needed in the client application. But where in the heck is struct
> screen prototyped? And how does one use the SCREEN* from newterm() to
> get a WINDOW* that many of the other calls require? I ran gdb on this

newterm creates a SCREEN, which happens to be the current one.
But just like initscr, it creates the corresponding stdscr, curscr.

> and told it to give me the value of the struct, and found it is rather
> large and complex, then did a recursive grep on the members from gdb,
> and still could not find the file with those members...is the actual
> struct only touched within the libraries, and all clients use only
> pointers, thus removing the need to declare the actual struct screen
> contents within client apps?
> D. Stimits, stimits AT attbi DOT com
> _______________________________________________
> Bug-ncurses mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-ncurses

T.E.Dickey <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]