Re: ncurses applications: best practices

[Stephan Beal]

See below - this is a resend with zipped attachments (i got a bounce
mail due to the attached .js file).

On Thu, Sep 25, 2008 at 2:08 PM, Stephan Beal <address@hidden> wrote:
> On Thu, Sep 25, 2008 at 7:26 AM, Sentinel <address@hidden> wrote:
>> Your advice has been great.
>
> :)
>
>> Sadly, all the examples one gets use stdscr for
>> writing. I was able to easily link my application files with my main menu
>> thanks to your advice.
>
> i'm looking for some examples in my code, but i think it's all in
> JavaScript. (i've got a JavaScript bindings for ncurses.)
>
>> However, what is written to stdscr does not get cleaned off. Do confirm
>> this: I should *NEVER* write to stdscr. Currently, my main menu is passing
>> stdscr to the constructor of the called programs. I think this should NOT
>> happen.
>
> In my opinion, stdscr is taboo and should never be written to except for:
>
> a) very, very simple cases
> b) to set up your overall screen attributes (e.g. maybe draw a border
> and set the bg color).
>
>> You advised a bottom panel for messages etc. Sounds great - I have to make
>> that change.
>>
>> * Defining colors on the fly *
>>
>> It seems to me that the init_pair way of defining a color_pair with a
>> running number disallows me from allowing my user to just say something
>> like: "label => "Hello", foreground => Color.blue"
>
> i'm attaching some code which makes this much, much simpler by
> defining a 64-color palette. One then calls:
>
> ulong color = color_pair( "blue", "white" ); // blue on white bg
>
> However, it needs C++. It can certainly be adapted to work with C, but
> i'm more of a C++ guy.
>
> Also, that code assumes that your terminal either has colors, or that
> the colors will gracefully fall back to useful black/white
> representations. That's not always an accurate assumption, but it has
> worked well for me so far.
>
>> in a definition file. Has anyone faced this issue? Any thoughts on this. I
>> think most programs like mutt/alpine etc allow users to define colors in a
>> user-friendly manner.
>
> IMO defining colors app-side is error-prone, problematic, and
> downright annoying. i've always used the attached code because then i
> have a predictable, publishable set of colors for my API.
>
> Aha - here's the JavaScript example i've got which uses panels - see
> ncpanel.js. It won't work for you as-is (it's JavaScript, after all),
> but you can see how it works. There are two mental translations you'll
> need:
>
> a) Where you see (new JCWindow(...)), think newwin()
> b) All NC API funcs have a prefix of "nc_" - just mentally remove that.
>
> :)
>
> --
> ----- stephan beal
> http://wanderinghorse.net/home/stephan/
>



-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/

panels.zip
Description: Zip archive