Cursor libraries

B

Blue Ocean

Are cursor libraries like Cygwin's (UNIX's?) ncurses.h platform
independent? Is there any way to make ISO standard C do the things
they do? Examples aren't necessary, I'd just like to know.
 
J

jacob navia

Blue Ocean said:
Are cursor libraries like Cygwin's (UNIX's?) ncurses.h platform
independent? Is there any way to make ISO standard C do the things
they do? Examples aren't necessary, I'd just like to know.

No. iso C doesn't have any notion of cursor, screen windows whatever.
The curses library has been ported to zig systems (windows, unix, and
several others), so it should be fairly portable if you like that kind
of look. But you will not find anything equivalent in iso C.
 
B

Blue Ocean

jacob navia said:
No. iso C doesn't have any notion of cursor, screen windows whatever.
The curses library has been ported to zig systems (windows, unix, and
several others), so it should be fairly portable if you like that kind
of look. But you will not find anything equivalent in iso C.

Oh, it's not really about the look, actually. I'm practicing with C,
and I'm trying to build a 2D physics simulator. I don't want to learn
win32 or GTK, and ncurses looked really easy, so I figured that I
would just represent particles with letters and then design a system
in which their internal position is rounded to the grid on the
terminal and printed as a letter. I don't think I can do this with
ISO standard C, if there is no curses library, so I will have to do
the physics itself standard, but make the UI nonstandard. Thanks much
though.
 
M

Malcolm

Blue Ocean said:
Are cursor libraries like Cygwin's (UNIX's?) ncurses.h platform
independent? Is there any way to make ISO standard C do the things
they do? Examples aren't necessary, I'd just like to know.
Semi. You will probably find an implementation of curses somewhere for most
common platforms. However it might not ship with popular compilers.
Unfortunately you cannot do any keyboard or screen manipulation at all with
ANSI C.
 
D

Dan Pop

In said:
Oh, it's not really about the look, actually. I'm practicing with C,
and I'm trying to build a 2D physics simulator. I don't want to learn
win32 or GTK, and ncurses looked really easy, so I figured that I
would just represent particles with letters and then design a system
in which their internal position is rounded to the grid on the
terminal and printed as a letter. I don't think I can do this with
ISO standard C, if there is no curses library, so I will have to do
the physics itself standard, but make the UI nonstandard. Thanks much
though.

In the real life, curses is as much of a standard as you can get (if you
stay away from the "extensions" provided by certain implementations).

Dan
 
T

Thomas Dickey

Dan Pop said:
In the real life, curses is as much of a standard as you can get (if you
stay away from the "extensions" provided by certain implementations).

In real life, all of the curses implementations have nonstandard features.
(Not all are documented ;-)
 
D

Dan Pop

In said:
In real life, all of the curses implementations have nonstandard features.
(Not all are documented ;-)

So what? After porting your program to a few such libraries, you get a
fair idea about what's portable and what not.

Another approach is to find an old BSD documentation of the curses
library: every other implementation is a superset of the original
BSD curses library.

Dan
 
T

Thomas Dickey

So what? After porting your program to a few such libraries, you get a
fair idea about what's portable and what not.

That comment negates your point.
Another approach is to find an old BSD documentation of the curses
library: every other implementation is a superset of the original
BSD curses library.

not really. There are analogous features, but it is not compatible.
 
D

Dan Pop

In said:
That comment negates your point.

Nope, it doesn't. When talking about the curses library, without any
qualifiers, one refers to the common subset of features.
not really. There are analogous features, but it is not compatible.

Concrete examples, please.

Dan
 
T

Thomas Dickey

Dan Pop said:
Nope, it doesn't. When talking about the curses library, without any
qualifiers, one refers to the common subset of features.

for that sort of attitude, you shouldn't post in comp.lang.c
Concrete examples, please.

getch behaves differently (as you would know if you'd done much porting).
delwin also.

The low-level flags (cbreak, crmode, etc) are also analogous but not compatible.
 
K

kal

Oh, it's not really about the look, actually. I'm practicing with C,
and I'm trying to build a 2D physics simulator. I don't want to learn
win32 or GTK, and ncurses looked really easy, so I figured that I
would just represent particles with letters and then design a system
in which their internal position is rounded to the grid on the
terminal and printed as a letter. I don't think I can do this with
ISO standard C, if there is no curses library, so I will have to do
the physics itself standard, but make the UI nonstandard. Thanks much
though.

Looks like you have arrived at a workable combination.

But I do think, probably mistakenly, that the task can be
accomplished using ISO standard C. I looked into the
termcap/terminfo stuff only once and that too out of
curiosity.

A portable program can be written to accept screen control
escape sequences at run time and then those can be used
to position output on the screen. This is essentially what
the various versions of curses do.

OTOH You can always output a screenfull at a time.
 
D

Dan Pop

In said:
for that sort of attitude, you shouldn't post in comp.lang.c

Why? What's wrong with advocating portable programming in c.l.c?
getch behaves differently (as you would know if you'd done much porting).

All my curses-based code simply worked anywhere I tried it. But I used
only the most basic features and had no problems with getch behaving
differently (as long as we're talking about the curses getch).
delwin also.

Never used it. All the descriptions I'm familiar with say basically the
same thing:

Calling delwin deletes the named window, freeing all memory
associated with it (it does not actually erase the window's
screen image). Subwindows must be deleted before the main
window can be deleted.
The low-level flags (cbreak, crmode, etc) are also analogous but not compatible.

I've asked for *concrete* examples, not for hand waving. Saying "behaves
differently" is not what I call *concrete*. "Analogous but not
compatible" even less.

Dan
 
T

Thomas Dickey

Why? What's wrong with advocating portable programming in c.l.c?

rephrasing your comment, let's simply code against the common denominator
of K&R C, C89 and C99.
All my curses-based code simply worked anywhere I tried it. But I used
only the most basic features and had no problems with getch behaving
differently (as long as we're talking about the curses getch).

BSD getch doesn't do a refresh, doesn't provide for returning function keys.
So it's not compatible.
Never used it. All the descriptions I'm familiar with say basically the
same thing:
Calling delwin deletes the named window, freeing all memory
associated with it (it does not actually erase the window's
screen image). Subwindows must be deleted before the main
window can be deleted.

some of the BSD implementations erase the window (more than one that I
used in the late 80's).
I've asked for *concrete* examples, not for hand waving. Saying "behaves
differently" is not what I call *concrete*. "Analogous but not
compatible" even less.

There's no 1-1 mapping between the half-cooked modes in the BSD and SysV
implementations (they're different enough to notice). That's generally
because the BSD code uses sgtty, which has fewer bits to work with. So
a program would have to deal with different control characters that wouldn't
be filtered by the library's settings.
 
D

Dan Pop

In said:
rephrasing your comment, let's simply code against the common denominator
of K&R C, C89 and C99.

Exactly, when the code *must* work on K&R C, C89 and C99 implementations.
What's wrong with that?
BSD getch doesn't do a refresh, doesn't provide for returning function keys.
So it's not compatible.

You're missing my point which was that, for portable code, you have to
rely on the original BSD specification. Which means that you cannot
support function keys. It's the age old trade off between functionality
and portability.
some of the BSD implementations erase the window (more than one that I
used in the late 80's).

So, clear the window before calling delwin and you couldn't care less
about whether delwin clears the window or not.
There's no 1-1 mapping between the half-cooked modes in the BSD and SysV
implementations (they're different enough to notice). That's generally
because the BSD code uses sgtty, which has fewer bits to work with. So
a program would have to deal with different control characters that wouldn't
be filtered by the library's settings.

Don't use half-cooked modes. In a full screen application, you really
want raw mode, so that you have full control over what happens when the
user presses a key.

Dan
 
T

Thomas Dickey

Dan Pop said:
You're missing my point which was that, for portable code, you have to
rely on the original BSD specification. Which means that you cannot
support function keys. It's the age old trade off between functionality
and portability.

or else use a portable library.

It's been easily 5 years since anyone but me has built lynx with BSD curses.
 
D

Dan Pop

In said:
or else use a portable library.

It's been easily 5 years since anyone but me has built lynx with BSD curses.

In the absence of external constraints, it is up to the programmer to
decide how portable his code should be. For maximal portability, there
is nothing better than what I have suggested in this discussion.

If you had a reason for using old BSD curses, it is not unconceivable that
someone else might have such a reason, too (e.g. a Domain/OS fan[atic]
using the 4.3BSD environment).

Dan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,145
Messages
2,570,824
Members
47,371
Latest member
Brkaa

Latest Threads

Top