bug-ncurses
[Top][All Lists]
Advanced

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

RE: ncurses++ and maintenance thereof


From: L. Dee Holtsclaw
Subject: RE: ncurses++ and maintenance thereof
Date: 24 Oct 2002 22:13:11 -0400

I already sent a reply (off list) to Mr. Dickey regarding extending
these classes to make them usable. As they are now, they are too limited
to be truly useful in a real-world application.

I don't mind taking these and running with 'em, including making them
Doxygen compatible so there will be documentation available. I'd say,
however, that the result will most likely be quite unlike they are now.

If, as you say, you'd rather keep them as they are, I'll respect that
and create a new set of wrappers from scratch. I cannot, however,
accomplish anything significant by simply deriving extension classes
since the base is so limiting. There are too many missing hooks and I
really have a personal problem with the naming convention, or rather,
the apparent lack of same -- makes the code *really* hard to follow.

I have experience in using, maintaining, extending and porting a
proprietary library [Vermont Views] so I was hoping to use that
experience and finally contribute to open-source myself.

Just let me know and I'll go from there.

Thanks.

Ciao,
Dee

On Thu, 2002-10-24 at 19:51, Jürgen Pfeifer wrote:
> > So... This brings the following questions:
> > 1. Is anyone maintaining these classes and, if so, how do I 
> > contact? 
> Not really. This was a weekend hack.
> 
> > 2. Are these classes in enough use to prohibit renaming some members?
> >
> Based on the almost zero feedback I don't think so. But who knows. 
> 
> >3. Is there any reason NOT to use some STL in the implementations?
> >
> The time this stuff was written STL was far from being usable with g++.
> That's different now.
>  
> > FYI, Some of the functionality I intend to add:
> > 1. Menu choices displaying details on a "status line" if so 
> > allocated 2. Current field details ditto 3. ESC key 
> > additionally available to exit-cancel a menu or form 4. 
> > Accessing Pad driver outside of Pad's own loop (for an 
> > external loop) 5. Swapping in new SLKs for active forms/fields
> > 
> All this can easily be done with the classes as they are. I prefer
> not to add all and everything into the classes but only what is
> available in the C APIs.
> 
> Jürgen






reply via email to

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