Next steps for Monkeybars + Rawr
February 22nd, 2010
As of today I am the admin for the Monkeybars and Rawr projects
I’m taking over from Logan Barnett who has, without a doubt, done a fantastic job with these projects. (And of course big props to David Koontz as well. David and Logan have been the magicians behind Monkeybars and Rawr.)
My immediate plans:
- Get acquainted with the current project.
The means not just going through the code, but getting more familiar with Kenai
These are forks of rawr and Monkeybars, created to make it easier for me to pursue certain design, packaging, and business goals. It worked well for me, but it’s less useful overall to have multiple projects that are kinda sorta the same.
I don’t want to impulsively just merge in the features that distinguish my forks, but I know that at least some of them have good use cases and should be made regular features.
However, I hope to get some feedback from current rawr and Monkeybars users to see how best to go about things.
It is quite likely that I will move things off of Kenai. I’ve never really liked the site; the mailing list has wonky navigation, and I’d prefer to just use github for the repo. Bug tracking is another matter. Github’s issue tracking is OK, but not terribly robust. Pivotal Tracker may be a better choice.
But there may be features or options in Kenai that I’m unaware of, especially regarding the integration of tools, so I need to do a bit of homework.
If you are a user of Monkeybars or Rawr let me know your thoughts on the Kenai services.
10 Responses to “Next steps for Monkeybars + Rawr”
Have some thoughts on this? See here for how to reach me.
February 23rd, 2010 at 02:12 PM
I prefer Github better than Kenai too.
By the way, since now, I hope to see more activity in Monkeybars project (more releases and more documentation).
February 23rd, 2010 at 05:49 PM
“By the way, since now, I hope to see more activity in Monkeybars project (more releases and more documentation).”
Already with the demands! This is crazy!
Actually, I need to see what’s what, where docs and screencasts are behind, and make a plan.
February 25th, 2010 at 02:34 PM
It was not a demmand, just a wish. I’ll be patient.
Good luck with Monkeybars project.
March 1st, 2010 at 06:22 AM
I use monkeybars and my main problems tend to be finding examples or hints when I’m trying to do something new. For example at the moment I’m trying to hook up focusGained event on a jtextfield but doesn’t seem to fire correctly so guessing I need some add_listener magic but will be some trial and error to figure it out.
In terms of other ideas I’m using monkeybars with bundler (0.9) and having yet come to packaging. I had it working for 0.8.7 before but haven’t updated to 0.9 and it seems it may be a little trickier. Any work on better gem support when packaging an app would be great, and I think trying to work with bundler sounds like a good idea given it’ll get very widespread use in the ruby world.
I’ll have a look at roir and jimpanzee. Never heard of before.
Thanks for taking on monkeybars.
March 1st, 2010 at 09:32 AM
“I use monkeybars and my main problems tend to be finding examples or hints when I’m trying to do something new.”
That tends to be my own gripe with most documentation. I like having API details, but I really appreciate good, varied, examples as well. I’m hoping I can get more of these in pace. There are some existing examples thanks to David and Logan, and I think over time these can be added to and expanded.
“For example at the moment I’m trying to hook up focusGained event on a jtextfield but doesn’t seem to fire correctly so guessing I need some add_listener magic but will be some trial and error to figure it out.”
This is the other side of Monkeybars, the use of Swing. It would be beyond the scope of Monkeybars to explain Swing, but it may be reasonable to try to accumulate some pointers for common scenarios.
“I’ll have a look at roir and jimpanzee. Never heard of before.”
These are forks created to scratch my own itch and to allow me to do things as I please. The most notably difference in Jimpanzee is a reliance on Neurogami::SwingSet, a library that wraps some basic Swing components. A somewhat recent addition to Monkeybars was the ability to use Ruby code that inherits from Swing classes as UI objects in the same way it uses compiled Java classes.
SwingSet builds on this to make it easier to create an app using only Ruby code. It employs the MiG Swing layout engine under the hood.
I also started on some prject generator code the produces 4 MVC files instead of Monkeybars usual 3. With SwingSet you get, for example, thing_ui.rb, thing_view.rb, thing_model.rb, and thing_controller.rb. The thing_ui.rb file is a Ruby class defined using SwingSet, in place of the usual Java code for the tuple’s visual form.
I now use Rhesus for all my generators, rather than trying to bundle too much with any app.t has an option of defining the location of a local jruby-complete.jar file so that it need not be downloaded each time you make a new project.
The Roir fork of Rawr used a different set defaults for creating new projects. It has an option of defining the location of a local jruby-complete.jar file so that it need not be downloaded each time you make a new project.
March 8th, 2010 at 02:09 PM
I take your point on swing vs monkeybars docs. I tend to be able to just find some swing examples and it’s obvious how to do it in monkeybars, but sometimes how to bind it together in MB is not obvious at all to me.
The case I quoted was a case of me using a subclass of text field from JIDE that seem to not emit focusGained correctly, completely unrelated to MB or Swing in the end.
Typical use cases for the basic models would be good to have though – JTable, JTree etc + common handling of the typical events. I’m slowly building this up myself in my apps as I go along and one becomes exponentially more efficient with more examples – even for cases one have not encountered but via ideas from the widgets/models/events one has put together elsewhere.
One thing I’d like to add on the wish list is better dialog support. I have managed to get some stuff working but not when setting the parent of the dialog. It works but things like placement on the screen isn’t great (I’m a trader with many screens so can be quite annoying getting a dialog showing up 3 screens away).
March 12th, 2010 at 12:54 PM
merge the fork :)
March 19th, 2010 at 04:32 AM
one thing i’m starting to get very interested in is being able to deal with gems in a better way when packaging the app.
I develop using bundler. I’d like to make it possible for rawr to pickup the gem dependencies and package the gems correctly.
I may have a look at this myself.
March 19th, 2010 at 02:11 PM
sundbp: If you list gems in build_configuration then it should be not too hard (!) to add code to rawr to read that and automagically unpack the gems to a fixed location.
Offhand, I’m not sure what else would be needed to ensure these files would be found on the load path, since by default the unpacked gems have version info in their directory names.
One concern, though, is that I would want to be sure my packaged app was shipping with the exact gem code I used for testing. So I would not want rawr to be unpacking gems as part of the bundling process.
It might be handy to have a rawr task that took care of gem unpacking, but so far I’ve been happy unpacking gems by hand and making sure the gem code works as expected and that my app loads files correctly
Also, I’ve not used bundler, except once when it was a requirement to install some app, and it failed miserably. Based on that, and what I’ve heard from others, I have no interest in it. It seems to solve a problem I don’t have.
March 23rd, 2010 at 10:23 AM
Fair enough. It requires some adjustments to make it work. I have a mental plan for how to do it and may have a go pretty soon.
btw, bundler also has the same intention as you in terms of trying to make sure you are using the same gem code and can lock to versions etc. It’s starting to stabilize now after a period of rapid development, you may want to check it out in a couple of months again.