August 11, 2014
Please move to canis gem

rbcurse will now not be updated or modified unless there is a bug reported or pull request.

The project canis has taken over rbcurse, and is a slightly economized and simplified version of rbcurse.

Textpad has been improved, but other widgets have been slightly simplified.

To install:

gem install canis

August 11, 2014
Issue with colors in ncurses

Acco to the ncurses documentation, the number of color_pairs one can create
using `init_color` is `COLOR_PAIRS` - 1. This comes to 32767 on my system.

However, i notice that after 255, the colors i create do not show up
correctly, so the limit seems to be 255. This usually does not affect an
application, unless it is a color demo, or you wish to show each color
on the same screen/pad. Or you wish to let the user cycle through all
colors, and select one.

The only way of making this possible, is to once again start using
color_pairs from one, but that means that existing items on the screen
that use that color pair will immediately change their color.

Maybe there is a bug somewhere in the code, or in my terminal setting (I
have tried both xterm-256color and screen-256color. The ruby program
that outputs colors on the screen (non-curses) does not have this issue

May 10, 2014
Split Layout

Split Layout gives us almost similar functionality as the stacks and
flows did, except that this will be able to recalc if window is resized.

This does not do any fancy calculations, so expects weightages to be
defined exactly and no variable objects in a split. one per split. this
keeps the code simple and the number of execution paths very limited.

This sort of winds up big changed or additions to the canis.
After testing various small things out, a v0,0,1 can be released.

May 9, 2014

I have a couple of layouts: flow and stack. Each does only one thing.
This is a much cleaner way of separating the logic of laying out,
allowing a user to install his own layout manager. Now the only thing is
to get one that allows user to do both stacks and flows. These two will
recalc the screen when the screen is resized.

May 6, 2014
Key Handling

I am trying out a new way of handling composite keys. This can also be
used for single keys but i am avoiding that for present. i am wanting to
separate the complex key processing from single keys since that adds a
lot of complication.

The main key_map allows us to store single keys, regexes, ranges as
keys, and a check is done against these to ascertain an action. However,
in the earlier system if a composite binding existed for a key, then a
single binding could not exist. That is like if we have bound “uu” to
enter an underscore then we cannot bind just “u” for normal insert.

Now i have separate composite bindings into another hash. This contains
a node as the value, the node contains an action/proc and a map/hash of
nodes. Its like a tree. So we can have 3 or 4 keys. You can have an
action bound to “a” and to “ab” and to “abc”.

We can also now use an array as a key and check for include, as we do
for range.

May 6, 2014

I was struggling with the speed of ESCAPE and double ESCAPE till i came
across ESCDELAY in ncurses. Apparently, curses automatically waits after
ESCAPE is pressed for one second for other keys so as to get function
keys. ESCDELAY can be reduced, but it still is slow.

In all this, i have removed wtimeout completely, and added nodelay. I
think once you put `nodelay` then `wtimeout` has no effect.

You can save mappings to a file in home, ncurses-keys.yml which is read

March 28, 2014
tabbedpane and buttons

tabbed panes have buttons
This is fine if mostly used in a window as TabbedWindow. I suppose
having the buttons as part of the widget was necessary rather than
putting them on another form which was really complicating the earlier
code. Earlier, iirc we had 3 forms on for tabs, on for buttons and one
for the main form. Now its one.

However, if we embed a TP in a regular form with other widgets, then the
button is irrelevant. I can ofcourse not give a button_type but still
the lower area is demarcated. I am not sure why the button is used in
the demo, and why the area is printed and taken up if not button.

Is this to be fixed ?

March 25, 2014

For the purpose of simplifying, I was looking at the libtcltk ruby code.
They essentially use the same approach as I have done.
They also use a hash for options, but i doesn’t look like they set it
into vars. they keep it in a hash.
the first param is checked for if its a hash then it is taken to be the
options. this way one doesn’t have to pass form as nil.

all symbols are converted to strings. we sort of do the opposite and
prefer symbols.

however, if we only keep in a hash, then any processing that needs to be
done cannot be done. i am concerned about property_changed etc.

to update the hash, there is a configure method.

i suppose the configure method could check for an array of
property_change elements and call the handler. but still no special
processing can be done if we keep a hash only.

Keeping in a hash means that no documentation will be generated.

Interestingly, the menubar uses a spec which is an array with elements
and a proc, so the entire menu can be defined. each menu also can take a
spec as an optional param.

March 24, 2014
Notes on simplification

While documenting the tutorial, I have these findings.

The DSL syntax is the cleanest. and it may be required for cases
like containers, trees, and definitely for stack and flow.

I think the hash syntax requires more internal work, but however, hash
works as a var argument, and is passed around. Again, stacks and flows
use the hash. I may not be able to get rid of the hash.

So we may be stuck with all three ways of widget creation.

I was trying smoe benchmarks of all three. I can’t say for sure since
the results differ with high iterations but seems that the DSL creation
is slowest. Hash is slightly slower than the conventional method calls.

I will have to think of other ways of simplifying.

November 8, 2011
bifurcating into core and others

Perhaps it would be better to divide rbcurse into rbcurse-core and then other packages or gems. This way core can remain more or less frozen and bug fixes can be released quickly without waiting for other features to stabilize. Changes in other packages can be made without disturbing core. Core can be kept backward compatible. And it can remain light with just form, window, field, buttons, list and perhaps textview. Other widgets can be put in other gems. The entire extras, UI patterns, experimental work.

There could be a rbcurse-experimental which moves to either core or standard as and when it stabilizes.

1. rbcurse-core - form, field, label, buttons, dialogs, basiclist, messagebox viewer, menus? , combo - basically whatever is required to run test2 and test1.rb. We must have a minimal number of programs to test for this. Actually, test2 incorporates a lot!

2. rbcurse-util menus?, textarea?, tabbedpane, tree tables, tabular, keylabel, progress, scrollbar, statusline,

3. rbcurse-extras vimsplit, multi-containers, masterdetail, directorylist etc statuswindow, rcommandwindow link, menulink, container

4. rbcurse-experimental resultset, Pad, subwin,derwin from window class, scrollform, app, stack/flow gmailfield

5. rbcurse-demos rfe, sqlc/m, dbdemo which can be installed and run from anywhere appemail This must be dependent on a specific version of core and util.

6. rbcurse-db database related work - resultsetview etc