I’ve just released version 0.3.3 of the ffi-ncurses gem. This fixes
the long-standing issue of not being compatible with ffi version
0.6.x. Apologies to all who requested this change months ago.
= What is ffi-ncurses?
A wrapper for ncurses 5.x. Tested on Ubuntu 8.04 to 10.04 and Mac OS X
10.4 (Tiger) with ruby 1.8.6, 1.8.7 and 1.9.x using ffi (>= 0.6.3) and
JRuby 1.5.1.
The API is a transliteration of the C API rather than an attempt to
provide an idiomatic Ruby object-oriented API. The intent is to
provide a ‘close to the metal’ wrapper around the ncurses library upon
which you can build your own abstractions.
On Wed, Aug 25, 2010 at 8:11 AM, Sean O’Halpin [email protected]
wrote:
A wrapper for ncurses 5.x. Tested on Ubuntu 8.04 to 10.04 and Mac OS X
10.4 (Tiger) with ruby 1.8.6, 1.8.7 and 1.9.x using ffi (>= 0.6.3) and
JRuby 1.5.1.
I’ve just released version 0.3.3 of the ffi-ncurses gem. This fixes
the long-standing issue of not being compatible with ffi version
0.6.x. Apologies to all who requested this change months ago.
thanks sean
the earlier version of ff-ncurses was not working on snow leopard, this
one is.
Any idea how to get the mouse to work on ncurses ?
(rvm ruby 1.9.2, OS X 10.6 Intel, bash)
If you were using this from a Linux console, you’d have to have gpm
running first. Don’t know if there’s anything special you have to do
for Snow Leopard.
Not clear what this implies. rbcurse does not use ncurses form or
menu. It implements forms and fields and menus in pure ruby, since
ncurses forms and fields are extremely painful, restricted and limited.
rbcurse uses only ncurses Window and Panel.
i was wrong then. i thought* rbcurse required ruby-ncurses… wc i
have had difficulty installing then especially when i shifted to 1.9
…
Or are you asking that ffi should implement ncurses form and menu ?
ffi-ncurses just runs without a need for ruby-ncurses… i was
thinking if rbcurse could go thru/require ffi-ncurses instead of
ruby-ncurses… apologies if i am wrong again on these
assumptions…
it would be great if ffi curses portability gets integrated w rbcurses
form & menu features.
best regards -botp
Not clear what this implies. rbcurse does not use ncurses form or
menu. It implements forms and fields and menus in pure ruby, since
ncurses forms and fields are extremely painful, restricted and limited.
rbcurse uses only ncurses Window and Panel.
Or are you asking that ffi should implement ncurses form and menu ?
On Sat, Aug 28, 2010 at 10:28 PM, Sean O’Halpin [email protected]
wrote:
I would rather work on a common
console abstraction for both ncurses and Win32 Console, then build
widgets on top of that. I’m planning to use rbcurse as a baseline for
what such an abstraction would have to support.
Not clear what this implies. rbcurse does not use ncurses form or
menu. It implements forms and fields and menus in pure ruby, since
ncurses forms and fields are extremely painful, restricted and limited.
rbcurse uses only ncurses Window and Panel.
i was wrong then. i thought* rbcurse required ruby-ncurses… wc i
have had difficulty installing then especially when i shifted to 1.9
Or are you asking that ffi should implement ncurses form and menu ?
I’m personally not keen to do this. I would rather work on a common
console abstraction for both ncurses and Win32 Console, then build
widgets on top of that. I’m planning to use rbcurse as a baseline for
what such an abstraction would have to support.
ffi-ncurses just runs without a need for ruby-ncurses… i was
thinking if rbcurse could go thru/require ffi-ncurses instead of
ruby-ncurses… apologies if i am wrong again on these
assumptions…
Your assumptions are correct but ffi-ncurses is not a drop-in
replacement for ruby-ncurses so there would be some work to convert
rbcurse to use it.
botp et al
There seems to be a little confusion on what i said regarding “ncurses”.
rbcurse does depend on ruby-ncurses but not for forms and menus.
The purpose of writing rbcurse was to be free of ncurses forms and
fields which are very restrictive.
Yes, i understand that ffi-ncurses goes directly to native ncurses and
not to ruby-ncurses.
Yes, I understand that ffi is not a drop in replacement. My problem in
converting is only that testing is very difficult, its a completely
manual process. I have not been able to automate, since most errors were
usually visual errors.
Also, sadly it seems no one is really using console apps today. All app
development has shifted to the web. So i don’t know if the effort of
shifting to ffi-nc is worth it. Sadly, no one is maintaining
ruby-ncurses as a gem. (Even after installing the gem on 1.8.7 yesterday
i still had to run make/make install since the bundle files were not
installed.)
If there is a need, and people find ncurses-ruby to be a pain, i will
gladly work to shift rbcurse to ffi.
If there is a need, and people find ncurses-ruby to be a pain, i will
gladly work to shift rbcurse to ffi.
Hi Rahul, rbcurse is cool; your work is cool. It’s the install
barrier of the ruby-ncurses that is keeping a lot of us fr using it
both in *nix and windows. If you and sean can pull this thru, i’d vote
to make it to ruby’s std lib and possibly req a rename of it to ruby
console… fwiw.
thanks for rbcurse and best regards -botp
What platform are you on ? While we work on moving rbcurse to ffi, can
someone not take over maintaining ruby-ncurses. My ‘C’ is poor or else i
would have, and i have access to only one laptop.
Wanted to confirm. Seems ffi-ncurses does not support panels. Panels are
critical when we need to have multiple windows. e.g. one screen leads to
another, and then closing a screen brings one back to previous. IIRC,
its also required for dialog boxes, popups etc.
Is it possible to have panel support. There are only a few methods:
If there is a need, and people find ncurses-ruby to be a pain, i will
gladly work to shift rbcurse to ffi.
Hi Rahul, rbcurse is cool; your work is cool. It’s the install
barrier of the ruby-ncurses that is keeping a lot of us fr using it
both in *nix and windows. If you and sean can pull this thru, i’d vote
to make it to ruby’s std lib and possibly req a rename of it to ruby
console… fwiw.
Yes, I understand that ffi is not a drop in replacement. My problem in
converting is only that testing is very difficult, its a completely
manual process. I have not been able to automate, since most errors were
usually visual errors.
I have the same issue. I’ve been thinking about how to automate visual
tests and have so far drawn a blank.
Also, sadly it seems no one is really using console apps today. All app
development has shifted to the web.
Well, think of it this way: we’re both doing our little bit to help
keep console apps alive.
I noticed in ncurses-example.rb that you’ve created a module and WINDOW
classes that makes your example exactly like the ruby-ncurses one, so no
change is required in the user’s code. That was great.
However, should that class not go into the main project at some time ?
Also, window should return its panel with window.panel().
thx
rahul
Indeed it is possible. I’ve added it to my roadmap which now looks like
this:
0.3.4: tidy up wide character support (almost ready to ship)
0.4.0: convert function signatures to semantic types (including using
:bool which will require existing apps to change) (half-done)
0.4.1: include Panel support
0.4.2: ruby-ncurses compatibility layer (investigating)
I’ll get onto 0.4.1 as soon as I’ve done 0.4.0 which should be some
time in the next week.
Unfortunate that I’m going to have to break API-compatibility to use
bools, but I don’t envisage any further changes that will break
backward-compatibility from 0.4.0 on.
On Mon, Aug 30, 2010 at 11:31 PM, Sean O’Halpin [email protected]
wrote:
Ncurses::Panel.new_panel
0.3.4: tidy up wide character support (almost ready to ship)
0.4.0: convert function signatures to semantic types (including using
:bool which will require existing apps to change) (half-done)
0.4.1: include Panel support
I can provide that, all the code exists already at:
However, should that class not go into the main project at some time ?
Yes, it will but it’s not exactly quite there yet.
I need to convert the functions which take booleans, e.g. keypad.
For example, in ffi-ncurses at the moment, you write:
keypad stdscr, 1 # or FFI::NCurses::TRUE which is extra fugly
I’ll be changing that so you write
keypad stdscr, true
That will break backward compatibility, but I think it’s worth it.
It means I won’t have to add translation functions for the ruby ncurses
layer.
I think it’s also more in the spirit of ffi type handling.
Thank you for rbcurse - it’s one of the things spurring me on to
improve ffi-ncurses.