RE: ncurses++ and maintenance thereof

[Jürgen Pfeifer]

The most reasonable approach is that you create a new style C++
binding using STL etc. etc.

We can put this into our distribution in parallel to the existing
one and do the following:

        - For some release cycles the new binding is declared Beta.
        - The new binding becomes "released", the old one is deprecated
        but still in the distribution
      - At some release in the future the old binding is removed.

Cheers
Jürgen

> -----Original Message-----
> From: L. Dee Holtsclaw [mailto:address@hidden 
> Sent: Friday, October 25, 2002 4:13 AM
> To: Jürgen Pfeifer
> Cc: Ncurses Mailing List; Thomas Dickey
> Subject: RE: ncurses++ and maintenance thereof
> 
> 
> 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
> 
> 
>