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
Layouts

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
escdelay

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
up.

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
constructors

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

November 3, 2011
color formatting

Alot has happened since moving to ffi. New widgets and containers, a new tabbedpane that hopefully doesn’t suck and is more rubyesque. However, its amazing how simple the color formatting issue was. Took me only a few minutes to get working with a good regular expression.

The motivation is to be able to have a document with color formatting. I am using the color formatting code of tmux, i.e., #[fg=green, bg=blue, bold] etc. However, I added an “#[end]” tag which pops the previous color, so now its more like html’s span, than the terminal escape sequences which just override the previous. I’ll ofcourse use this in the statusline, in help screens, and also in some way in textview, and somehow even in messages, alerts, messageboxes etc. It’s still rough, does no checking for mistakes and I don’t have a routine to wrap text ignoring the color stuff. That will be needed soon.

Edit: I’ve also now added ANSI formatted text in textview

September 17, 2011
porting to ffi-ncurses

I’ve been working on porting the rbcurse gem to ffi-ncurses, since ncurses gems is so so hard to install for a lot of people. Thanks to Sean’s support the work and retesting was actually very little. It’s just that there is a lot of testing to do with all the programs, widgets. Sean is coming out with a version 0.4.0 which I am using. rbcurse 1.3.0 onwards uses ffi-ncurses.