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

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.

September 17, 2011
App.rb confirm before quit

App should be able to configure whether it wants quit-confirm. Or a procedure to call before quitting, such as saving values. It’s okay for demos where there’s no state to just press F1 or q or C-q to quit.

December 1, 2010

Just installed calcurse (port) and was checking the UI. Neat. Some salient points: 1. Windows or panels. Standard with title, title border, border color changes when focus in panel or box (that’s because it keeps updating time and thereofre cursor remains on status bar) 2. 2 bottom lines for keys like we have (keylabels) 3. 3rd last row is a sort of status bar like emacs and vim have 4. Data entry in last 2 rows. 2nd last has prompt, last has entry or edit 5. Similarly menu options selected in last row. A page comes with options, letter indexed. 6. Allows layout change of panels. 7. Allows color change, immediate change. Displays colors rather than name. Color chooser for BG and FG.

November 20, 2010
gmail style email completion

I’ve just implemented some gmail style email completion. As you type in a field, values are shown in a window. You can key UP or DOWN, or keep typing. Pressing ENTER selects highilghted value. You can enter multiple emails in one field and get help on each. However, in this case, the window is not modal, so the form below is painting itself. There are still some old widgets like Label and Field (perhaps button) that keep repainting redgarldess of whether changed. This overrides the non-modal window. I’ve just fixed field but putting a @repaint_required == true check in repaint. Also, i think its possible, that rcommandwindow does a repaint and panel update more often than required. its called in different ways, interactive and non-interactive. Need to look into that at some time.

November 4, 2010

Regarding bottomline and rmessagewindow I was thinking that if i try to do bottomline in a separate window that just pops up and goes off, then i don’t have to worry about having a window handle (since a new window is created with each call). I tried out this approach with rmessagewindow. However, first of all one has to press a key to make the message go off. Secondly, when the window goes off, so does the message. Whatever was there before remains. Which is great if that’s what you need. (But we already have alert() and rdialog for that). This is fine for accepting input at screen bottom, but after ask() we still want to display some message like “file written” and let it be there. Which means i still have to write to existing window, so my problem remains. I need to have handle of existing window. I’ve added a bottomline object in each window when we create so we can use it as @window.ask, @window.agree. When you use App, you automatically get ask() connected to the root window, but what happens when one App calls another App!! However, i really like how i can do a ‘M-x’ (taken from memacs), and then tab to see available commands. This way user does not need to remember key combinations.