Just hopping on this thread after reading through the various takes on
things. For me, I love using Ruby for quick and dirty scripting. The
language itself is compact, intuitive, and doesn’t clutter up my
coding needlessly. But one of the big frustrations I’ve experienced in
the past is trying to come up with a GUI app using it. This started
back about 5 years ago now, when I was looking out there at the
various Ruby GUI toolkits. Trying them out, none of them really seemed
to reach out and grab me. Took the wind out of my sails for sure.
That was around the time Rails was just coming out, and so there wasn’t
the level of interest on Ruby that there is now. From what I can tell,
there’s been a lot going on with Ruby GUI tools in the last 2-3 years.
When I think of GUI programming and using an IDE for such I think of
drag and drop widgets, automated event bindings, etc. But after
banging my head against my desk I had to resort to my tried and true
Visual Studio install using Visual C#.
I don’t think I can even consider that for a project that has to not
just run on Windows.
Since Ruby took a good amount of its inspiration and foundation in
Smalltalk, I’d look at that as an example where a dynamic programming
language can have a tightly integrated GUI development environment and
pull it off well. It is possible, and to me that is one of the main
things holding Ruby back from “the big time” in terms of standing toe
to toe against Java, C#, and other languages.
Smalltalk may well be my second choice for this project, if I can’t find
the tools to do it in Ruby. But I actually would prefer Ruby.
Really? Under what circumstances? Even “can’t-change-anything”
corporate deployments tend to have a usable JVM.
I administer a couple of machines at work running FreeBSD (one of them
mainly used as a server, one for development), and my main machine at
home
also runs FreeBSD, all without Java.
If you want maximum cross-platform,
you shouldn’t rely on having Java.
Got a better idea, short of dropping Ruby for this project? Native
packaging on wx?
Personally, I’d take another look at FXRuby or Tk. (I’ve never used
wxRuby, so I really don’t know its pluses and minuses.) Maybe JRuby is
the
right way to go for your purposes, but you shuold realize that presence
of
Java is not universal.
Studio in the first place :-/
Expected disclaimer: I helped with Monkeybars and Rawr, and now maintain
forks (Jimpanzee and Roir), plus wrote Neurogami::SwingSet for wrapping
Swing items in a nicer Ruby API.
One of the selling points for using JRuby + Swing is the use of NetBeans
and its built-in GUI editor.
It’s drag-and-drop, but no automated event integration. I doubt that’s
a big loss; the integration in Monkeybars between the view and the
model+controller is decoupled to make testing easier, something you’d
lose with event integration in the IDE.
You can write complete JRuby Swing apps in NetBeans, running the code
straight from the IDE. I still prefer doing my code editing in Vim (and
the NetBeans vi plugin isn’t quite all I’d want it to be), and running
tasks from the command line, but NetBeans is a solid JRuby IDE, and the
GUI editor is sweet. And it’s free.
I prefer wxRuby for gui development. For distrubution on windows
machines I
use OCRA which will create an exe of my app so the client does not need
anything to run the app.
Really? Under what circumstances? Even “can’t-change-anything”
corporate deployments tend to have a usable JVM.
I administer a couple of machines at work running FreeBSD (one of them
mainly used as a server, one for development), and my main machine at
home
also runs FreeBSD, all without Java.
If you want maximum cross-platform,
you shouldn’t rely on having Java.
Got a better idea, short of dropping Ruby for this project? Native
packaging on wx?
Personally, I’d take another look at FXRuby or Tk. (I’ve never used
wxRuby, so I really don’t know its pluses and minuses.)
I’m shying away from Tk since I understand the API is awful (and I don’t
like the look of Tk apps that much), but FXRuby looks pretty impressive.
One question, though: what’s the state of FXRuby on Mac OS? I don’t
want to stick Mac users with only an X11 app. I’m a bit nervous that
none of the production apps listed as FXRuby examples seem to support
Aqua, but I don’t know if that’s the fault of the framework. It appears
that it may be, since the FOX toolkit definitely does not support Aqua
according to its own website.
wxRuby, on the other hand, definitely does support Aqua.
I prefer wxRuby for gui development. For distrubution on windows
machines I
use OCRA which will create an exe of my app so the client does not need
anything to run the app.
That could work, although I’m trying to not have radically different
build processes for different operating systems. (But the user is
paramount – if I have to have a weird build process, so be it.)
Along those lines…is it feasible to create Aqua apps with
rubyscript2exe? If so, that looks promising.
And then there’s Crate, which looks marvelous. Is it?
Again, I’m sorry about the idiotic tone of these questions. I haven’t
done much desktop app development in a long time (I usually do Web
apps), and never anything this ambitious. Since I can’t easily swap out
my basic framework, I’m trying to choose a good one at the beginning.
Got a better idea, short of dropping Ruby for this project? Native
packaging on wx?
Personally, I’d take another look at FXRuby or Tk. (I’ve never used
wxRuby, so I really don’t know its pluses and minuses.) Maybe JRuby is the
right way to go for your purposes, but you shuold realize that presence of
Java is not universal.
I would argue that these machines are a special case. Since he’s said
that he’s working on a desktop application, then the server machines
are
“right out”. As for desktops, the vast majority of them will have java.
It may not be universal, but it’s certainly more available without
requiring users to install additional software than Tk. Moreover, with
JRuby, all of the dependencies, as well as the application, can be
shipped
in a single jar file, or distributed via WebStart, which makes for a
relatively pain-free install.
I would argue that these machines are a special case. Since he’s said
that he’s working on a desktop application, then the server machines
are
“right out”.
Correct.
As for desktops, the vast majority of them will have java.
It may not be universal, but it’s certainly more available without
requiring users to install additional software than Tk.
Well, the only reason I’m even considering something other than JRuby is
that it appears that there are ways of packaging up MRI into native apps
that don’t require a system Ruby interpreter. No way am I going to make
my end users install Tk/wxRuby/whatever to run my app.
Moreover, with
JRuby, all of the dependencies, as well as the application, can be
shipped
in a single jar file, or distributed via WebStart, which makes for a
relatively pain-free install.
And Web Start is another reason I was attracted to JRuby – it should be
possible for even users who can’t install my app to run it through Web
Start…
Yes, I think you’re right here. It’s possible to create fully native
packages using wxRuby etc, but there’s no single cross-platform tool
like RAWR. You have to use a mix of tools, eg Ocra for Windows, Platypus
for OS X.
Just for the record…both of these tools look good, but extremely
platform-specific. Is there an equivalent for Linux? Google hasn’t
turned up anything useful, but I may well not be looking for the right
things. Or am I just meant to rely on the distro’s package manager?
On Thu, Oct 29, 2009 at 4:29 PM, Marnen Laibow-Koser [email protected]
wrote:
One question, though: what’s the state of FXRuby on Mac OS? I don’t
want to stick Mac users with only an X11 app. I’m a bit nervous that
none of the production apps listed as FXRuby examples seem to support
Aqua, but I don’t know if that’s the fault of the framework. It appears
that it may be, since the FOX toolkit definitely does not support Aqua
according to its own website.
Yes, it is a fault of FOX. There is no “native” version of FOX for OS
X, and I don’t expect there to be one any time soon. Part of the “why”
of this is that unlike wxWidgets (and some other toolkits), FOX draws
its own widgets and implements their behavior instead of just mapping
to native widgets. This approach has its advantages and disadvantages,
but one of the big disadvantages is that you sacrifice the native look
and feel.
Haven’t had a chance to play with it yet but it sounds like it might be
worth consideration.
It looks beautiful, but the tutorial app is somewhat slow and has
display bugs. I see that it’s pretty new, though; it’s got potential to
become the new Shoes…
