Often, when people talk about Monkeybars, they compare it to some other similar tool that uses inline code (often using a “builder”-style syntax) to define the UI. The typical Monkeybars demo, in contrast, shows the use of WYSIWYG UI editor to create a binary Java Swing class; this file is then used in the Monkeybars app.
Not surprisingly, showing how this is done can take some time, even for a basic Hello, World! demo app. The sad truth of conference talks and demos is that you can get screwed from both ends in trying to properly explain anything non-trivial. You want to point out the details (because your tool is powerful), but that eats up the limited time available. You also want to actually show something, ideally something complete, so you end up with something simplistic.
If done well, then everyone gets the point: robust, sophisticated tool presented in overly-simplistic app for demonstration purposes. However, you can often end up with people seeing it the other way: lots of detailed steps needed to get to skimpy results. What’s then not grasped (or not well explained) is that the details are there to convey the breadth of possibilities; the skimpy app is there to simply demonstrate that this is something real. You still have to apply some imagination to understand the implications for larger, far more complex applications by extrapolation.
Demos using hand-written code to define a GUI have a real edge here because the speaker never has to leave the code editor, never has to switch views or tools, never has to explain much more than “here’s some more Ruby.” What’s often not mentioned, though, is that the inline-style of GUI definition does not scale well beyond the typical demo program. What you see really is what your get. (Trust me; I would not want to have to work on JotBot hand-coding the UI.)
Of course, maybe you don’t want much more than a handful of buttons and some text fields. Maybe all you want is the desktop equivalent of HTML 3.2.
Sometimes that’s all I need for given screen in some larger app, and having Monkeybars provide this would make it that much sweeter. Best would be that it would not alter how one uses the full power of the library.
So here’s what my fork of Monkeybars adds:
Some code to the base View class to aid in detecting when the Swing UI class is in fact created via Ruby, so that the appropriate reflection/meta-programming can be done
An additional app generator that gives you an MVC tuple, with a basic view UI class, written in Ruby, in place.
Because I’m interested in getting people to play with this, I renamed the key files from monkeybars to jimpanzee. Now if you install the code as a gem you won’t stomp on any existing Monkeybars installation. (The code should be completely compatible with the current actual Monkeybars API, but the renaming is cleaner.)
With jimpanzee, you can do this:
james@james06:~/tmp$ jimpanzee MyCoolApp :demo
Creating directory MyCoolApp
Copying jimpanzee project structure
Creating default code for MyCoolApp ...
Final steps:
1. Place a copy of jruby-complete.jar in the MyCoolApp/lib/java directory
2. cd into the MyCoolApp/src directory
3. Run the code using jruby:
jruby main.rb
Happy hacking!
and if you follow those final instructions you’ll have a simple cross-platform GUI app running. Toss in rawr and you’re three steps away from having redistributable executables ready.
There’s more to be done, not the least of which is ensuring that my approach is robust. The generator needs improvement; it’s pretty brain-dead. (For example, :demo is a hard-coded flag for the generator code, and you can’t tell it what to name the generated tuple. But these are not difficult things to change. The real issue is what to change them to.)
There’s a certain “gee whiz” factor in this, because there’s a low limit on what such generators can buy you, and how much inline UI code you’ll want, but the flip side is that it does lower the barrier to entry, and it is of practical value when coupled with Monkeybars’ other killer features. The best part is that it is in addition to, not in place of, all the power the best GUI toolkit offers for creating robust GUI apps of all shapes and sizes.
Please keep in mind when you see any demo that looks a bit too good or too easy that maybe the cool comes with a cost. The most common is that what makes some things easy ends up making other things hard. Always try to ask the presenter what the limits are, if a tool will grow with you if the size your application expands, or if will you find yourself stuck once the gee whiz has worn off.
Previous Topic
