On Tue, Aug 26, 2025 at 01:17:01AM +0200, Jakub Horký wrote:
> po 25. 8. 2025 v 23:20 odesílatel Thomas Dickey <[email protected]> napsal:
> 
> >
> > > In general, I think there shouldn't be such an incompatibility gap as in
> > > the transition from classic (or *-256color) to *-direct TERMs, even if
> > > color numbers are not officially standardized.
> > >
> > > So I'd like to ask your opinion: Would adding such a compatibility layer
> > be
> > > a good or bad idea?
> >
> > I have in mind a different scheme, which would allow for RGB when available
> > to be used explicitly.  No compatibility layer.
> >
> 
> May I ask what scheme you have in mind?

There are several parts, taking into account ABI compatibility with plans
for a new ABI 7.  Changing the size of attr_t requires a new ABI, which
takes more time than most people can imagine.

In the existing ABI 6, seeing that there are no existing uses of sgr1,
to use the corresponding A_xxx bits to support a color palette for
the 24-bit colors.  This chunk in curses.h was more convenient to
add, a few months ago, than keeping it in a branch:

        #if 1   /* NCURSES_EXT_FUNCS */
        #define A_ITALIC        NCURSES_BITS(1U,23)     /* ncurses extension */
        #if 0   /* NCURSES_RGB_COLORS */
        #define A_FOREGROUND    NCURSES_BITS(1U,17)     /* ncurses extension */
        #define A_BACKGROUND    NCURSES_BITS(1U,18)     /* ncurses extension */
        #define A_DIRECT        (A_FOREGROUND|A_BACKGROUND)
        #endif /* NCURSES_RGB_COLORS */
        #endif /* NCURSES_EXT_FUNCS */

It would have to be a (limited-size) palette, for both compatibility and
performance reasons.  Aside from people playing with pictures, a limited
size is fine.

That involves

        a) changes to tic to provide for this

        b) sample terminfo

        c) modify vid_puts and vid_attr

        d) modify lib_color (e.g., to support alloc_pair)

        e) new utility functions (a second alloc_pair, etc., is expected)

        f) develop/test/measure examples to show the old/new schemes.

        g) documentation...

So... that's binary-compatible with existing code, adding new functions
for handling the extension.  I worked on that during January-May, got up
to working on (d), which presents some problems to work on.

Completing the work would probably take six months or more,
assuming no distractions.  Those happen.

-- 
Thomas E. Dickey <[email protected]>
https://invisible-island.net

Attachment: signature.asc
Description: PGP signature

Reply via email to