bug-ncurses
[Top][All Lists]
Advanced

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

Re: A colouring api that doesn't suck


From: Mahlon Smith
Subject: Re: A colouring api that doesn't suck
Date: Tue, 03 Sep 2019 11:17:16 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

Hello Elijah,

Perhaps I don't understand the reasoning behind your arguments.

I apologize if I sound preachy, but standing in front of students for 15 years may have warped my personality.

As a curses (Solaris) and ncurses (GNU/Linux) developer for many years, I will point out that it would be unwise for any professional application to embed ncurses primitives directly in the application flow as your pseudocode suggests. NCurses should always be encapsulated in some way and at some level of abstraction. It is the choice of abstraction that determines whether one's development is allowed to focus on the conceptual or tends to become mired in process.

Here comes the gratuitous plug:

You may find some ideas which would be useful for your projects at:

http://www.SoftwareSam.us/

Specifically, see the “NcDialog API” library and its demonstration apps.

It may not be what you need, but:

WriteParagraph ( short y, short x, const wchar_t* text, attr_t color, bool refresh = false, bool rtl = false ) ;

is a cleaner template that what you suggest.

Best regards,

Mahlon (Software Sam)





On 08/11/2019 08:16 PM, Elijah wrote:
frequently what I see (and have to write all too often) is something
like this (pseudocode):
This is addressed in the FAQ - 
https://invisible-island.net/ncurses/ncurses.faq.html#backlog
(you can certainly write and maintain an add-on library to do what's suggested)
If you mean to make a library that integrates that colour pair lookup 
table to implement the *_ext functions I proposed, I don't think that's 
a solution.  Mostly because no one would use it :P.  The added 
complexity of integrating such a library wouldn't be worth the ease it 
added, when it wouldn't be much harder than making the same 
functionality in-house.  But also because it wouldn't actually solve the 
problem.  You still can't display a full complement of colour pairs. 
(Otherwise you wouldn't need the lookup table!  You could just do 
init_pair((fg << 8) | bg, fg, bg) for every fg, bg from 0 to 255.)

If the bottleneck is your ability to work on it, I would be 100% willing 
to write a patch implementing this extension.  I just want to know if it 
would be welcome or if I would be wasting my time.

  -E

(Double-sent because I didn't send to the mailing list the first time, 
by accident.)



_______________________________________________
Bug-ncurses mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-ncurses

--

Software Sam - software and tools for GNU/Linux

Mahlon Smith,
The Software Samurai
On the Web: http://www.SoftwareSam.us/


reply via email to

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