One thing I’ve spent a lot of time working on for the last few weeks is a Shoes Console. Why, when you can get the pretty Shoes Console just be typing cmd-/ and write to it with with a debug or info command?
What separates Shoes 3.2 from our friends at Shoes 4 is that Shoes 3.2 caters to native gems and native widgets and native packagers and native … and when it comes to native Ruby developers and C developers often write puts statements of call printf(). If you run Shoes from the command line those puts and printf() display on that terminal (aka console). If you start a Shoes program from the Windows Manager or Menus then those messages have no place to appear. Also, starting Shoes from the command line on OSX is what I would call “painful” just to see puts and printf()’s and not all that beginner friendly on Windows or Linux.
Shoes Console is also written in Shoes/Ruby which can be mixed blessing. Microsoft has an AllocConsole() C function which will create a new console window, if needed, and redirect all stdout/stderr/stdin there. Pretty damn awesome! Linux and OSX can’t do that. What if I could write a console for Shoes/Linux and Shoes/OSX that could behave the same way?
So I did for Shoes 3.2.24. On Linux and OSX it’s a native Window that Shoes doesn’t control or can’t control. No Ruby code. Gtk (Linux) and Cocoa(OSX) windows that redirects stdin/out/err for the Shoes program to the (New) Shoes Console window.
If you think about use case’s it becomes clear that the Shoes app developer already knows when his scripts/gems/process should have a console (it’s not easy or convenient or overkill to convert puts/printf() into Shoes para or teach the end user how to launch from a terminal. In Shoes 3.2.23 we did provide a limited way to do this for packaged apps for windows by using the –console command line argument (and a script driven packaging method).
Now, (when 3.2.24 is released) all you have to do is at the beginning of your Shoes script is call
Shoes::show_console. No special packaging requirements. Works on Linux and OSX and Windows. Don’t need it?, Don’t call it. It does work different on Linux, OSX and Windows because – wait for it … because it’s native. It’s also lowest common denominator so you need to know some bewares:
readline gem works, Barely. io-console (raw or cooked) is platform dependent so don’t use it. A pure Ruby version of the readline gem is included with Shoes 3.2,23+. Odds are high you can’t get the up/down arrow keys or your vi/emacs keystrokes. It may or may not handle UTF-8 input keystrokes.
It knows nothing about escape sequences. Repeat NOTHING. You can not send it color settings codes for Windows and expect them to work anywhere else. You do get backspace and tab but the tab stops are not settable.
Since the Windows version uses AllocConsole() some of that escape sequence nonsense might work for you and your app but not for your users who have doctored up their console or don’t run Windows. The Windows Console is pretty lame so people jazz it up with all kinds of yucky hacks. Not a problem I can solve nor can you.
The Gtk & OSX consoles are also pretty lame. You get a copy button and a clear button which works on every thing displayed up to when the clear button was last used. No selection and Ctl/X/V/C unless you get lucky on that platform/theme.
It’s also slow (OSX) and may it not keep up with lots of puts/printfs and/or it may slow down what is doing all the printf() with hangs for buffer full. Did I mention escape sequences are not handled?
It’s also pretty damn cool if can live with the limitations.