The Accidental Rubyist

invalid byte sequence in UTF-8

The Future of rbcurse (ruby ncurses)

with 14 comments

A year back I had split rbcurse into rbcurse-core and extras and experimental. Of late, I have been working on a widget called *textpad* to replace textview. It uses pads (which i earlier abhored and avoided) and this really simplifies the logic. I have also used the same textpad as a list, so that now obviates having a separate list class (unless I need to do multiple selection).
I have tested textpad as a textview and a list and a popup in a gem called cygnus. It is the ncurses version of the cetus gem which uses the terminal (I actually use cetus, cygnus is mostly to test out textpad).

I am also working on a replacement for tabular_widget using the same textpad. It extends textpad and only adds a minimal amount of code, but allows most of what tabular_widget allowed, while making it easier to override the rendering. I will release it after using it a little more in my current project. That mostly leaves replacing tree with a pad version.

However, my issue then is how to release these. I could replace the old widgets, but that won’t be backward compatible, and I have made things simpler, so i cannot be totally backward compatible. I could add these to the current project and request people to move over to these new widgets. I could release these as a separate gem….

My next goal after that is to seriously trim down the base. That is form and widget, and also Window, utils etc. This will definitely break everything and require a new gem. There is a lot of stuff that makes the base complex but may never be used. There is also code that really needs a rewrite such as Button and Menu.

About these ads

Written by totalrecall

April 10, 2013 at 5:22 pm

Posted in ruby

14 Responses

Subscribe to comments with RSS.

  1. I just discovered this project and I feel like I just discovered the world. Keep the good job ;) This is awesome!


    May 29, 2013 at 6:57 pm

  2. I’ve been working on a curses music player (i’ve been using moc for a few _years_ but want something a bit “better”. I found your libraries but i couldn’t make much sense of the documentation. Lots of stuff that needed definition that i couldn’t figure out. The comment i want to make, though, relates to your saying that one of your prime goals is to maintain backward compatibility (as well as simplify the code base). How many people currently use these libraries? If it were hardly anyone, really, then i wouldn’t waste my time and energy maintaining backward compatibility. Just a thought.


    July 16, 2013 at 4:04 am

  3. You are right, there are very few users. I guess I would have to bump the major version or just create a new gem so there is no confusion if an older user updates his gem. Or if a user distributes a gem that depends on rbcurse and the new version breaks compatibility, then his users would not be able to use his product.

    This is preventing me from moving the changes into rbcurse-core for some of the improvements i have made.


    July 16, 2013 at 11:17 am

  4. You are obviously at the alpha stage. You should separate your current work from whatever existed before, that worked. (?) and devote all your time and energy to doing the development work that is your primary interest and of the greatest importance to you. If you have any users who depend upon previous code and yet you have no awareness of their existence, then they should be of no concern to you. They are being served by the old code, as it is, as well as can be expected. The whole issue is one of focusing limited time and energy to accomplish something that, if too much time and energy are diverted, may not get done satisfactorily, or at all. A higher level curses library would be a nice thing to have. Ncurses is very stable and something equally stable on top of that would have value for years to come. However, it needs to be well-designed.

    After reading some of what you’d written about how your development is proceeding, i decided not to take a shot at using it because what exists at the moment seems to be a mish-mash of old and in-process (and the documentation was incomprehensible).

    Personally, i don’t think a higher level library on top of ncurses should be too complicated. Looking at what you’ve got, it seems like there is far too much junk there, relative to the amount of good, solid, well-designed code that is implemented and available. (Some good functionatliy may be available now, but, in my view, not cleanly, because of the way things are packaged.)

    I used a library called stfl to implement what i could for my project. It’s pretty well-designed and easy to use, and works well for what it does. It seems to be completely abandoned at this point, though, and i dropped it because it didn’t have any means for doing certain basic things, like being able to change the color of a line in a list. Other widgets had a style property (including color) but not list _items_.

    If i were you, i’d start by packaging together the functionality that you now have that you’re happy with and make your top priority working on those things that are then missing from what you have that is most urgently needed. Package this up and release it as soon as possible and from there, that will be your work in progress. It needs to be functional, though, for anyone else to use it and therefore help you with further development (if only as testers).

    Take that all for what it’s worth. Finally, if you feel you _do_ have something that is usable which you could package cleanly, i’d be willing to give a shot at using it to implement my player program. This will be a relatively (but not overly) simple application which should exercise most of the functionality needed from a higher level curses library without getting into a lot of bells and whistles that aren’t appropriate for a library that doesn’t even have a stable release yet. Of course, you’d have to explain your mysterious documentation to me. :-)


    July 16, 2013 at 9:12 pm

  5. Your comments are correct and extremely valuable. I have always been afraid of cutting out the cruft and cleaning it up due to backward compatibility. I will read your post several times and then decide exactly how to go about it.

    The only way you can use this is to study the examples and use the code from there. The documentation is mostly useless. That is how others have used it.

    I essentially messed it up trying to implement something very complicated – the ability to have things like splitpanes within splitpanes and scrollpanes etc. This complicated the entire code. Finally, i gave that up and tried to remove all the stuff I had added to get that functional, but i never could clean it totally since many other things got added and fixed along side.

    That is why i tried to cut out stuff into rbcurse-core but even that has stuff i want to cut out. If i can forgo backward compat as you suggest, then it is easy for me. I have implemented much better and cleaner widgets but cannot replace them for the compat issue.

    If we ditch back-compat then i can replace older widgets with cleaner ones. I can cut out lots of code from the basic widget and form. Maybe even Window.

    Thanks for your candid feedback. Anything more you want to say is most welcome. Be free to be blunt and critical.


    July 17, 2013 at 1:46 am

  6. really great job totalrecall
    i try tu use rbcurse-core i creat a function ( load_avg ) for print the load on my server
    but i cant find how to print the output ?
    could you help me please


    January 21, 2014 at 10:54 pm

  7. You wish to print the load avg on what. A list ? Or a textarea ? or a textbox or label ?

    What kind of screen / form do you have ? Is this something that keeps updating ?

    Create a LABEL and place it on the form. Keep updating the value of the label whenever your avg changes or periodically.

    Please check examples in the examples folder such as test2.rb


    January 21, 2014 at 11:29 pm

  8. I agree with Craig. I think the objective of higher level programming is to simplify the task and take the language in out of our way. In the process, we usually get workarounds that can be worse than the languages. What keeps people from programming is not ability. It is the programming language and their feeble minded tutorials. The dynamic array is what is driving the Cloud which has left us behind learning their static (noisy) tutorials based on stack architecture. The dynamic array is everything. You can do structs without struct and class with class. It is what is fueling the dynamic explosion of scripting languages. Of course there are techniques to make this happen and they are extremely simple and thus mostly overlooked. To that end, for all the times Ruby ncurses make it impossible to program a dynamic and non static menu system despite have the most dynamic arrays of any language. By Ruby I mean 1.8.X. I don’t know 1.6.X but 1.9.X is where I get off! These are the reasons why I say Ruby is dead. Thy want you to use Java Ruby (jruby) instead.


    August 30, 2014 at 10:16 pm

  9. > To that end, for all the times Ruby ncurses make it impossible to program a dynamic and non static menu system despite have the most dynamic arrays of any language

    Ruby ncurses (or rather ffi-ncurses) is only a ruby wrapper over ncurses so it suffers from the same deficiencies such as not beign able to make a flexible menu system as you pointed out. Or change the screen, or properties of controls. That is why this project was created. It only uses the Window and Pad of ncurses and builds over that, so you are not limited by ruby ncurses.

    Currently, the project “canis” has taken over the code and is being worked upon. It is being simplified and cruft removed. rbcurse will not be changed now, other than bug fixes. Canis will have all the improvements.


    August 30, 2014 at 11:05 pm

  10. Powerbase’s comment is tantalizing but i can’t say i competely follow it. Was that “with_out_” classes? Anyway, i’m _still_ using moc (and postgres, datamapper and a bunch of ruby scripts i wrote). It works great for me, but the weak point is moc. Thanks for the tip on canis. I’m looking at the documentation now.


    August 31, 2014 at 3:30 am

  11. There is no documentation as such, as yet. What exactly are you looking at. What URL?

    The classes and methods have been documented to *some* extent, and examples of usage have been put in a few places. Right now there are small changes and additions and deletions that keep popping up.

    There are a couple of gems that are using canis as well.


    August 31, 2014 at 10:35 am

  12. By the way, since you folks are responding, I have been thinking of a minimal version of rbcurse called mini-curse or something. I understand that rbcurse started simple but then just snowballed out of control trying to do too much.

    As a single person, i just cannot handle such a large code-base. Add to that, I am completely unable to automate testing of an ncurses library, given that most issues/bugs are visual.

    I’d like to somehow cut rbcurse down to the bare minimum, but provide handles so that users can extend it , so complexity can be added at the user level.
    That was my idea for rbcurse-core, but even core was too large.

    Any ideas from you would be very welcome.


    August 31, 2014 at 10:42 am

  13. This is the page i was referring to:

    Haven’t really scrutinized it much, yet, but it looks interesting. I definitely think i’ll d/l and look more. When is always the question. As far as your solicitation for ideas… i don’t have any at the moment. But i wonder what the relationship is between what you have in mind and canis? I don’t have an overview of canis yet, but what about contributing to that? Or is there such a gap between what you have in mind and what they’re doing that that doesn’t make sense to you? Also, do you see a “niche” need for what you have in mind? Generally speaking, what you mentioned (very vaguely understood by me) seems to be the sort of thing that serves best as the foundation for further work, building more elaborate (and more functional) layers on top of it (like canis?). But where does canis fit with that? I’m presuming they build directly from ffi-ncurses? In terms of separation of layers (at least conceptually) they might be better served by building off a slightly higher level layer than ffi-ncurses. So i can (potentially) seem so folding of your idea into canis in that way. But coordination and willingness to (and feasibility of) working together are crucial (and difficult) elements in that kind of situation. Or maybe you just want something more “single-person” scale you can work on yourself? Personally, i would select the higher level toolkit for my own use unless it failed so fundamentally in achieving a solid basic design that i felt i’d be better off rolling my own starting with something more primitive. To digress to more general philosophizing, over-design is the key failing i see in software (that and an inability to see the need — or be willing to bite the bullet — when refactoring is required to maintain the integrity of a clean design). So someone will think of 10 features they imagine would be good, then having bitten off more than they could really chew, end up with a bad/unclean implementation. Whereas, i, maybe starting from a lower level toolkit, can add the 1 or 2 things i really need and be better served than using the (supposedly) more sophisticated, higher-level toolkit.


    August 31, 2014 at 9:16 pm

  14. First of all, canis has taken the code of rbcurse and is modifying, simplifying, refactoring it.
    Second, rbcurse was originally built over ncurses, but later modified slightly to use ffi-ncurses (since ruby ncurses was a pain to install for most people).

    I started rbcurse after looking at various toolkits including tk, Swing and a glancing at Qt’s docs and the docs of various other existing toolkits. So i was taking features from everywhere. At some point, since i had worked for many years in Java and also used Swing, i tried to build a lot of Swing into this, which is why it became more and more complex.

    For many months I went crazy trying to implement scrollpanes and splitpanes, and the issue would be when you placed them several levels deep. Finally, i cut all that out.

    Your post addresses several issues which i will try to think more deeply about, and reply to. But one thing I would like to do is work on the documentation of Canis.

    Everyone has complained about the documentation of rbcurse (or lack of it). Could you give me some ideas on what the documentation should be like. You need not reply immediately, but if you can get back in a week or two, would appreciate it.

    The tutorial for rbcurse lies at:

    Could you glance at it and tell me it’s failings and how it could be made useful (for canis). I will change it to suit canis based on whatever feedback i can get.

    I just had a glance at the documentation link you gave me. I don’t think you’ll ever make head of tail looking at that. You will have to look at the examples folder and run some examples to see what they do, and then check out the classes involved.
    You will also have to see the tutorials.

    I guess the main documentation page you mentioned should also be more detailed, so users know what too look at first (such as Window and Form and Textpad, List, App, Field etc).


    September 1, 2014 at 12:14 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: