Cursor libraries

[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.

[jacob navia]

Re: Cursor libraries


"Blue Ocean" <blueoceanz1@ho tmail.com> a écrit dans le message de
news:3349b232.0 407041542.39eff d0@posting.goog le.com...[color=blue]
> 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.[/color]

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.

[Blue Ocean]

Re: Cursor libraries

"jacob navia" <jacob@jacob.re mcomp.fr> wrote in message news:<cca5lc$bd h$1@news-reader4.wanadoo .fr>...[color=blue]
> "Blue Ocean" <blueoceanz1@ho tmail.com> a écrit dans le message de
> news:3349b232.0 407041542.39eff d0@posting.goog le.com...[color=green]
> > 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.[/color]
>
> 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.[/color]

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.

[Malcolm]

Re: Cursor libraries


"Blue Ocean" <blueoceanz1@ho tmail.com> wrote[color=blue]
>
> 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.
>[/color]
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.

[Dan Pop]

Re: Cursor libraries

In <3349b232.04070 50718.31dccb56@ posting.google. com> blueoceanz1@hot mail.com (Blue Ocean) writes:
[color=blue]
>"jacob navia" <jacob@jacob.re mcomp.fr> wrote in message news:<cca5lc$bd h$1@news-reader4.wanadoo .fr>...[color=green]
>> "Blue Ocean" <blueoceanz1@ho tmail.com> a écrit dans le message de
>> news:3349b232.0 407041542.39eff d0@posting.goog le.com...[color=darkred]
>> > 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.[/color]
>>
>> 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.[/color]
>
>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.[/color]

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Thomas Dickey]

Re: Cursor libraries

Dan Pop <Dan.Pop@cern.c h> wrote:
[color=blue]
> 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 ).[/color]

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

--
Thomas E. Dickey

http://invisible-island.net

ftp://invisible-island.net

[Dan Pop]

Re: Cursor libraries

In <10ep42rrrqveof 0@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:
[color=blue]
>Dan Pop <Dan.Pop@cern.c h> wrote:
>[color=green]
>> 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 ).[/color]
>
>In real life, all of the curses implementations have nonstandard features.
>(Not all are documented ;-)[/color]

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Thomas Dickey]

Re: Cursor libraries

Dan Pop <Dan.Pop@cern.c h> wrote:[color=blue]
> In <10ep42rrrqveof 0@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:[/color]
[color=blue][color=green]
>>Dan Pop <Dan.Pop@cern.c h> wrote:
>>[color=darkred]
>>> 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 ).[/color]
>>
>>In real life, all of the curses implementations have nonstandard features.
>>(Not all are documented ;-)[/color][/color]
[color=blue]
> So what? After porting your program to a few such libraries, you get a
> fair idea about what's portable and what not.[/color]

That comment negates your point.
[color=blue]
> 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.[/color]

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

--
Thomas E. Dickey

http://invisible-island.net

ftp://invisible-island.net

[Dan Pop]

Re: Cursor libraries

In <10eqff2fhu2d2c b@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:
[color=blue]
>Dan Pop <Dan.Pop@cern.c h> wrote:[color=green]
>> In <10ep42rrrqveof 0@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:[/color]
>[color=green][color=darkred]
>>>Dan Pop <Dan.Pop@cern.c h> wrote:
>>>
>>>> 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 ;-)[/color][/color]
>[color=green]
>> So what? After porting your program to a few such libraries, you get a
>> fair idea about what's portable and what not.[/color]
>
>That comment negates your point.[/color]

Nope, it doesn't. When talking about the curses library, without any
qualifiers, one refers to the common subset of features.
[color=blue][color=green]
>> 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.[/color]
>
>not really. There are analogous features, but it is not compatible.[/color]

Concrete examples, please.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Thomas Dickey]

Re: Cursor libraries

Dan Pop <Dan.Pop@cern.c h> wrote:[color=blue]
> In <10eqff2fhu2d2c b@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:[/color]
[color=blue]
> Nope, it doesn't. When talking about the curses library, without any
> qualifiers, one refers to the common subset of features.[/color]

for that sort of attitude, you shouldn't post in comp.lang.c
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>>
>>not really. There are analogous features, but it is not compatible.[/color][/color]
[color=blue]
> Concrete examples, please.[/color]

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.

--
Thomas E. Dickey

http://invisible-island.net

ftp://invisible-island.net

[kal]

Re: Cursor libraries

blueoceanz1@hot mail.com (Blue Ocean) wrote in message news:<3349b232. 0407050718.31dc cb56@posting.go ogle.com>...
[color=blue]
> 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.[/color]

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.

[Dan Pop]

Re: Cursor libraries

In <10er4jhhdq6ch0 b@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:
[color=blue]
>Dan Pop <Dan.Pop@cern.c h> wrote:[color=green]
>> In <10eqff2fhu2d2c b@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:[/color]
>[color=green]
>> Nope, it doesn't. When talking about the curses library, without any
>> qualifiers, one refers to the common subset of features.[/color]
>
>for that sort of attitude, you shouldn't post in comp.lang.c[/color]

Why? What's wrong with advocating portable programming in c.l.c?
[color=blue][color=green][color=darkred]
>>>> 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.[/color][/color]
>[color=green]
>> Concrete examples, please.[/color]
>
>getch behaves differently (as you would know if you'd done much porting).[/color]

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).
[color=blue]
>delwin also.[/color]

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.
[color=blue]
>The low-level flags (cbreak, crmode, etc) are also analogous but not compatible.[/color]

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Thomas Dickey]

Re: Cursor libraries

Dan Pop <Dan.Pop@cern.c h> wrote:[color=blue]
> In <10er4jhhdq6ch0 b@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:[/color]
[color=blue][color=green]
>>Dan Pop <Dan.Pop@cern.c h> wrote:[color=darkred]
>>> In <10eqff2fhu2d2c b@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:[/color]
>>[color=darkred]
>>> Nope, it doesn't. When talking about the curses library, without any
>>> qualifiers, one refers to the common subset of features.[/color]
>>
>>for that sort of attitude, you shouldn't post in comp.lang.c[/color][/color]
[color=blue]
> Why? What's wrong with advocating portable programming in c.l.c?[/color]

rephrasing your comment, let's simply code against the common denominator
of K&R C, C89 and C99.
[color=blue][color=green][color=darkred]
>>>>> 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.[/color]
>>[color=darkred]
>>> Concrete examples, please.[/color]
>>
>>getch behaves differently (as you would know if you'd done much porting).[/color][/color]
[color=blue]
> 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).[/color]

BSD getch doesn't do a refresh, doesn't provide for returning function keys.
So it's not compatible.
[color=blue][color=green]
>>delwin also.[/color][/color]
[color=blue]
> Never used it. All the descriptions I'm familiar with say basically the
> same thing:[/color]
[color=blue]
> 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.[/color]

some of the BSD implementations erase the window (more than one that I
used in the late 80's).
[color=blue][color=green]
>>The low-level flags (cbreak, crmode, etc) are also analogous but not compatible.[/color][/color]
[color=blue]
> 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.[/color]

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.

--
Thomas E. Dickey

http://invisible-island.net

ftp://invisible-island.net

[Dan Pop]

Re: Cursor libraries

In <10et3r293ujh35 e@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:
[color=blue]
>Dan Pop <Dan.Pop@cern.c h> wrote:[color=green]
>> In <10er4jhhdq6ch0 b@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:[/color]
>[color=green][color=darkred]
>>>Dan Pop <Dan.Pop@cern.c h> wrote:
>>>> In <10eqff2fhu2d2c b@corp.supernew s.com> Thomas Dickey <dickey@saltmin e.radix.net> writes:
>>>
>>>> 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[/color][/color]
>[color=green]
>> Why? What's wrong with advocating portable programming in c.l.c?[/color]
>
>rephrasing your comment, let's simply code against the common denominator
>of K&R C, C89 and C99.[/color]

Exactly, when the code *must* work on K&R C, C89 and C99 implementations .
What's wrong with that?
[color=blue][color=green][color=darkred]
>>>>>> 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.
>>>
>>>> Concrete examples, please.
>>>
>>>getch behaves differently (as you would know if you'd done much porting).[/color][/color]
>[color=green]
>> 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).[/color]
>
>BSD getch doesn't do a refresh, doesn't provide for returning function keys.
>So it's not compatible.[/color]

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.
[color=blue][color=green][color=darkred]
>>>delwin also.[/color][/color]
>[color=green]
>> Never used it. All the descriptions I'm familiar with say basically the
>> same thing:[/color]
>[color=green]
>> 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.[/color]
>
>some of the BSD implementations erase the window (more than one that I
>used in the late 80's).[/color]

So, clear the window before calling delwin and you couldn't care less
about whether delwin clears the window or not.
[color=blue][color=green][color=darkred]
>>>The low-level flags (cbreak, crmode, etc) are also analogous but not compatible.[/color][/color]
>[color=green]
>> 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.[/color]
>
>There's no 1-1 mapping between the half-cooked modes in the BSD and SysV
>implementation s (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.[/color]

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Thomas Dickey]

Re: Cursor libraries

Dan Pop <Dan.Pop@cern.c h> wrote:[color=blue]
> 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.[/color]

or else use a portable library.

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

--
Thomas E. Dickey

http://invisible-island.net

ftp://invisible-island.net