rbcurse 1.1.5 → 1.2.0.pre

data/CHANGELOG

@@ -1,3 +1,48 @@
+**2010-09-11**
+## 1.2.0
+
+### Additions
+
+ - App class that allows easy application development (like Shoes)
+ - MultiSplit class: Multicolumn widget (like SplitPane but allows many splits). 
+   aka Column Browse pattern (like OSX Finder). See examples/testmultisplit.rb
+ - Added Progress Bar class
+
+ - Added methods to Menu (rmenu.rb), so easy creation through DSL. See
+ examples/menu1.rb
+
+ - Added VimSplit - can have multiple splits stacked and flowed
+ - Added Tree     - tree control
+ - Added Scrollbar class
+ - Added Tabular - quick readonly tabular data generator that can be used with
+ listboxes or textviews.
+ - Added BasicList - a stripped down, readonly version of Listbox.
+ - 
+
+### Changes
+
+ - Field class now passes InputDataEvent when firing event, not self.
+   Earlier, user trapping :CHANGE would not know what happened (delete,
+   insert, etc) and what char was added, deleted.
+ - List and ListData and ListSelection listener
+   Many changes, new methods, def list(), space bar selects,
+   List listens to selection changes, selectionEvent contains List as source
+   not ListSelectionModel.
+ - Widget checks event names before firing and binding to save time in wrong
+ events.
+ - Listbox, some refactoring of `repaint`. Added convert_value_to_text since
+ we subclass this a lot.
+ - Listcellrenderer: refactoring and changes, will break extending classes!!
+ - Combolist - popup on spacebar
+ - replaced to_print_borders with suppress_borders in list related classes
+
+### Bugfixes
+
+ - TextArea would crash if user entered long line with no space (line >
+ display length) - fixed
+
+ - Menu items will not show mnemonic highlighted, if disabled. 
+   They will not fire if mnemonic key pressed, when disabled.
 
 **2010-08-30 11:59**
 ## 1.1.4

data/Makefile

@@ -1,5 +1,5 @@
 DISTFILES := README.markdown TODO2.txt NOTES lib/ examples/
-VERSION := `cat VERSION_FILE`
+VERSION := `cat VERSION`
  
 #all: install
 

data/Manifest.txt

@@ -0,0 +1,91 @@
+CHANGELOG
+History.txt
+Manifest.txt
+README.markdown
+Rakefile
+lib/rbcurse/action.rb
+lib/rbcurse/applicationheader.rb
+lib/rbcurse/celleditor.rb
+lib/rbcurse/checkboxcellrenderer.rb
+lib/rbcurse/colormap.rb
+lib/rbcurse/comboboxcellrenderer.rb
+lib/rbcurse/defaultlistselectionmodel.rb
+lib/rbcurse/io.rb
+lib/rbcurse/keylabelprinter.rb
+lib/rbcurse/listcellrenderer.rb
+lib/rbcurse/listeditable.rb
+lib/rbcurse/listkeys.rb
+lib/rbcurse/listscrollable.rb
+lib/rbcurse/listselectable.rb
+lib/rbcurse/mapper.rb
+lib/rbcurse/orderedhash.rb
+lib/rbcurse/rchangeevent.rb
+lib/rbcurse/rcombo.rb
+lib/rbcurse/rdialogs.rb
+lib/rbcurse/rform.rb
+lib/rbcurse/rinputdataevent.rb
+lib/rbcurse/rlistbox.rb
+lib/rbcurse/rmenu.rb
+lib/rbcurse/rmessagebox.rb
+lib/rbcurse/rmulticontainer.rb
+lib/rbcurse/rmultitextview.rb
+lib/rbcurse/rpopupmenu.rb
+lib/rbcurse/rscrollform.rb
+lib/rbcurse/rscrollpane.rb
+lib/rbcurse/rsplitpane.rb
+lib/rbcurse/rtabbedpane.rb
+lib/rbcurse/rtabbedwindow.rb
+lib/rbcurse/rtable.rb
+lib/rbcurse/rtextarea.rb
+lib/rbcurse/rtextview.rb
+lib/rbcurse/rviewport.rb
+lib/rbcurse/rwidget.rb
+lib/rbcurse/scrollable.rb
+lib/rbcurse/selectable.rb
+lib/rbcurse/table/tablecellrenderer.rb
+lib/rbcurse/table/tabledatecellrenderer.rb
+lib/rbcurse/undomanager.rb
+lib/rbcurse/vieditable.rb
+lib/rbcurse.rb
+lib/ver/keyboard.rb
+lib/ver/keyboard2.rb
+lib/ver/ncurses.rb
+lib/ver/window.rb
+examples/keytest.rb
+examples/mpad2.rb
+examples/newtesttabp.rb
+examples/qdfilechooser.rb
+examples/rfe.rb
+examples/rfe_renderer.rb
+examples/rvimsplit.rb
+examples/sqlc.rb
+examples/sqlm.rb
+examples/test1.rb
+examples/test2.rb
+examples/testchars.rb
+examples/testcombo.rb
+examples/testkeypress.rb
+examples/testmenu.rb
+examples/testmulticomp.rb
+examples/testscroller.rb
+examples/testscrolllb.rb
+examples/testscrollp.rb
+examples/testscrollta.rb
+examples/testscrolltable.rb
+examples/testsplit.rb
+examples/testsplit2.rb
+examples/testsplit3.rb
+examples/testsplit3_1.rb
+examples/testsplit3a.rb
+examples/testsplit3b.rb
+examples/testsplitta.rb
+examples/testsplittv.rb
+examples/testsplittvv.rb
+examples/testtable.rb
+examples/testtabp.rb
+examples/testtestw.rb
+examples/testtodo.rb
+examples/testtpane.rb
+examples/testtpane2.rb
+examples/testtpanetable.rb
+examples/viewtodo.rb

data/NOTES

@@ -735,13 +735,13 @@ Subject: microemacs user setup tabbedpane
 -----------------------------------------
 Date: 2010-01-30 00:06
 
-Micremacs has user setup tabbedpanes.
+Micremacs has user setup tabbedpanes. (Use F1)
 Left and right keys are used to move from one tab to another.
 
 Tab jumps to form associated with a tab. Tab does not cycle between
 tabs. IN some fields, where there are selectable values (combos) a "v"
 is shown but i am not clear how to access that list. Pressing Enter
-opens up the config file.
+opens up the config file. (Use spacebar)
 
 * * * * * * * *
 
@@ -1652,3 +1652,350 @@ use ffi or ruby-ncurses. For example, i read that mutt can be compiled
 for ncurses or slang.
 
 * * * * * * * *
+
+Subject: on_enter
+-----------------
+Date: 2010-09-02 12:12
+
+i think Form calls `on_enter` of a widget and also fires its `:ENTER`.
+However, looking at the on_enter of some widget;s looks like they also
+fire :ENTER. So things could get fired 2 times.
+
+* * * * * * * *
+
+Subject: making rbcurse easier
+------------------------------
+Date: 2010-09-05 10:57
+
+Currently making an application in rbcurse, requires a lot of boiler
+plate code. Various methods to be called to setup ... heck even I can't
+remember them! 
+
+I am trying out a wrapper for rbcurse. Much like a file.open block which
+does the dirty work of opening and closing a file while the user only
+supplies a block. 
+
+Then i need to make wrappers for fields and other widgets so they can be
+made easily. This way basic screens can be developed rather easily.
+
+The wrapper is called app.rb and it currently resides in examples since
+it is very much in progress and trial. it will keep changing, so its
+going to remain in examples till it grows up. If you use it, rename it
+first, let me know of any improvements or fixes or changes or ideas.
+
+* * * * * * * *
+
+Subject: shoes changed
+----------------------
+Date: 2010-09-05 15:08
+
+In rbcurse, we use the block to initialize... shoes uses the block as a
+changed action. Is that not better, since there is already a config for
+doing the setting. Why 2 ways of setting ?
+
+Is it too late to change, or shall we go this way in the App wrapper.
+Internally we can bind to CHANGED. or should i have a changed method
+which does this.
+
+* * * * * * * *
+
+Subject: uniformity and less surprises
+--------------------------------------
+Date: 2010-09-07 20:17
+
+we need more uniformity and less surprise. Let 'text' be the one method
+with 'def text' and 'def text =', in buttons rename text to label, so 
+text can be the answer. Same for all widgets. getvalue and get_value etc
+sucks.
+If a Variable passed in take its value.
+thanks to the DSL approach there's this whole get_ set_ nonsense.
+
+We need to move out the DSLish crap everywhere, even if that means a new
+major revision.
+
+* * * * * * * *
+
+Subject: testing of widgets
+---------------------------
+Date: 2010-09-19 10:59
+
+If we keep the model separate, we can test the model out. Helps if the
+model is complex like a tree, but what if the model is an inbuilt one
+such as a list ? 
+
+If the widget keeps UI separate, which includes ncurses, then we can run
+tests on it from command line. However, widgets are instantiated with
+form and window.!!! How to do change this ?
+
+
+Can i create objects without passing a form ? and then call methods on
+it, like setting data, set_value, add etc. See that events are fired,
+exceptions are raised ?
+
+actually even form is okay, but window printing is the issue. we need to
+prevent that, windowless form that handles keys sent by a program. but
+no ncurses loaded or displayed.
+
+* * * * * * * *
+
+Subject: temporarily leaving ncurses
+------------------------------------
+Date: 2010-09-20 13:23
+
+If i want to run some command, temporarily leave ncurses using
+def_prog_mode do stuff and then return. SEE:
+http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/misc.html#TEMPLEAVE
+
+I think vim does this when you type :ls . One can use this to display
+bindings, events etc.
+
+* * * * * * * *
+
+Subject: repainting of containers
+---------------------------------
+Date: 2010-09-22 18:15
+
+Seem to be screwing this up. Either I am painting all in repaint which
+is not good. Yet, i do not know which are updated. Perhaps one component
+has been externally updated, and the container does not know. So its
+repaint required is still false.
+
+So ... if `repaint_required` is true, it should repaint the borders, the
+components, resize etc.
+
+If `repaint_required` is *false*, it still must call `repaint()` on all
+components, which will repaint if they have been modified. I've done
+this in rvimsplit.
+
+* * * * * * * *
+
+Subject: Listbox and CellRenderer
+---------------------------------
+Date: 2010-09-23 22:25
+
+Often what is displayed in a listbox is quite different from the data in
+the list provided. Such as filenames in the list, but a long list is
+dislpayed.
+There are several ways to handle this.
+I am not addressing obvious performance vs memory issues here. Only
+implementation issues and their diffculties wrt display and app
+programming.
+
+1. Keep file names in list. But use the cell renderer to show complete
+   info. The repaint method truncates and treats the values from list,
+   so scrolling can't happen. The main program has a false idea of line
+   length. So cell renderers should only be used for format or color the
+   data, changes in length etc should not happen. Else we will have to
+   rewrite repaint and do length and scolling in renderer.
+
+2. Keep the formatted data in the list. This makes it difficult to do
+   work on firing the list. We don't have the filenames. We would have
+   to maintain a backing store. There are additional issues such as if
+   we are updating a list, the value shown will be the entire formatted
+   line, and that will be updated into the formatted list.
+
+3. So now we use `convert_value_to_text` to format the data, so scrolling
+   can happen. Cellrenderer just does coloring based on select focus etc
+   which was the original purpose. But since the formatted data is not
+   in the list, movement methods like end of line, forward word don't
+   work correctly since they consider the original data not the
+   formatted data.
+
+Currently, Listbox does not have a separation of methods that act on
+displayed data and actual (model) data. It assumes one list.
+Listbox already is complicated enough with all the editing.
+
+I've gone back and forth with moving the formatting in and out of hte
+list, (in appdirtree and directorylist.rb) and i am doing no more. My
+suggestion is. ... perhaps you should put formatted data into the list
+itself. Have a backing store of the real data (that's what crow and
+row_index are for). However, in some case, you will have to face the
+difference between the 2 when updating only the model value.
+
+
+Some of hte performance considerations. If you have very long lists but
+only little of the data is seen by user the creating formatted date for
+all rows can be wasteful. Cellrenderer and convert_value_to_text only
+work on the rows beign displayed. However, they will keep working on the
+rows if you keep viewing them over and over. No cacheing etc.
+If you put formatted data in the list, there would be no repeated
+formatting. In the directory lister demo, there is no cacheing of file
+stat objects. Since the speed is fine, i did not bother to do any
+cacheing.
+
+One option is to maintain a cache of only those objects on screen.
+Populate the cache in the convert_value_to_text loop. Or in
+cell_renderer. Clear it every time you get a row_index of 0 and start
+over.
+This way all operations that require movement over formatted data can
+use that cache.
+
+* * * * * * * *
+
+Subject: grabbars and scrollbar focusing
+----------------------------------------
+Date: 2010-10-07 11:49
+
+
+
+* * * * * * * *
+
+Subject: grabbar and scrollbar focusing
+---------------------------------------
+Date: 2010-10-07 11:49
+
+Some objects like grabbars should not be in the way. they should be
+`focusable` on some key, or condition. I am thinking of Alt-Tab.
+Should there be some extra attrib for such since focusable will be
+false.
+
+I could register such objects with a `FocusManager` array. Upon pressing some
+key (say F2), it cycles through these and makes then focusable. Works as
+a toggle.
+Or on pressing F2, it goes to next object in its array. So it will cycle
+between these objects directly setting focus to them. So they will never
+come in the TAB order.
+
+This means i don't have to make a parallel `select_next_field` for such
+objects since they will have focusable true.
+
+* * * * * * * *
+
+Subject: grabbars and other strange things
+------------------------------------------
+Date: 2010-10-08 18:25
+
+I've added these grabbars (dividers) for forms that have many panes. These are
+borders (much like a scrollbar) that allow user to drag them left right
+or up down and re-size panes. Currently, the alternative has been to use
+keys such as C-w - and +, which may not be obvious.
+
+However, we don't want these dividers to take focus each time a user
+traverses the form. Thus, dividers are not focusable by default. But we
+add them to a module FocusManager. When F3 is pressed, the FocusManager
+toggles these dividers (or whatever it has in its list), to focusable.
+Now the user can tab into these dividers. Once the user is done, he may
+press F3 again and make them non-focusable. FocusManager can be used for
+amy objects that should only be focusable when user wants them. I may
+make scrollbars focusable in a future version.
+
+* * * * * * * *
+
+Subject: stacks and flows - thoughts
+------------------------------------
+Date: 2010-10-17 22:40
+
+It should be possible to maintain stacks and flows within the app class.
+this way, the app can be asked to reposition the widgets and it can do
+so. This is required for when we get into using KEY_RESIZE (window
+resizing). So this will only be available within App, but then that's
+where stacks and flows are, anyway.
+Can we liberate S and F from App and make them independent ?
+
+* * * * * * * *
+
+Subject: color_pair added to widget
+-----------------------------------
+Date: 2010-10-18 23:04
+
+Now we may directly pass a color_pair to a widget when creating. This
+way we can create one color_pair and pass it to multiple widgets, rather
+than passing actual colors to each. Also, this is a tad more efficient
+since the color won't be calculated each time a repaint is done.
+
+* * * * * * * *
+
+Subject: Usage of preferred_size
+--------------------------------
+Date: 2010-10-20 13:02
+
+when the user may resize a component, or columns in a components, or
+user may specify widths or heights, we should use a `preferred_width`
+field. 
+When we calculate width, use `preferred_width` if present, else calculate
+it. Program never updates `preferred_width`.
+
+However, the question is what when a user resizes a component or
+sub-component. We want to respect that and not overwrite. So currently,
+i suggest that we update preferred_width on resizing, dragging etc. This
+does mean that the original specified width is lost, so a
+`reset_to_preferred_sizes` is not possible.
+
+* * * * * * * *
+
+Subject: single and multiple selection and keys
+-----------------------------------------------
+Date: 2010-10-28 23:07
+
+If single selection (by spacebar) then pressing spacebar and pressing
+Enter should typically have same action. i.e. select current row and
+fire_event.(*)
+
+If multiple selection, then Enter typically fires an action for current
+row such as opening an item or giving more details for that item.
+Spacebar selects multiple items (or Ctrl-Spacebar), and other keys will
+execute some action on selected rows (like delete, flag, move etc).
+
+(*) Exceptions: in tree, Enter collapses or expands, and selects current
+row, whereas spacebar only selects and displays in other window.
+Spacebar does not expand or collapse tree node.
+
+Typically in multiple select, spacebar selects first row (deselecting
+others) and Ctrl-Spacebar continues selection. Have to check this out
+with Listbox. including `ListSelectable` should take care of most of this.
+
+* * * * * * * *
+
+Subject: rmessagewindow
+-----------------------
+Date: 2010-11-04 12:23
+
+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.
+
+* * * * * * * *
+
+Subject: gmail style email completion
+-------------------------------------
+Date: 2010-11-20 13:26
+
+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.
+
+* * * * * * * *