Re: Native gem roundup!

Logan Barnett wrote:
On Feb 4, 2009, at 5:54 PM, Adam Gardner wrote:
Perhaps you're following the MVC pattern, and the Model and perhaps
Controller are written using normal old ruby code (perhaps with some
java stuff thrown in), and then you create a distinct View for
different
platforms. Of course, I'm sure you could use Swing or AWT or something
(I'm not too familiar with Java GUI frameworks)... it'd be a lot less
effort, but with OS X GUI applications, if the interface is not done
in
Cocoa or Carbon, it usually sticks out like a sore thumb.

Java Swing apps (including JRuby ones, like when you write a
Monkeybars app - http://monkeybars.rubyforge.org/) by default on Macs
will render components using the System Look and Feel, which under the
hood will use the OS's native code to render buttons and other
widgets. Check out an app like FrostWire (http://www.frostwire.com/ -
Java) or JotBot (http://getjotbot.com/ - JRuby with Monkeybars)

SWT (not to be confused with AWT) is much more close to native look
and feels, but I think it marries you a lot more to a particular
platform. Check out Azureus for an SWT app in Java
(http://www.azureus.com/
). Glimmer is the only JRuby SWT framework I know of -
https://rubyforge.org/projects/glimmer/

Either way you go, it's possible to make apps that look good and look
native, but how many apps look like iTunes that you'd say also look
native? Pages doesn't look like iTunes, yet it looks native. What
about Colloquy? I think a native look is a fuzzy definition. The most
important thing is that you app does something useful, and does it
easily. That's not to say there isn't value in making a nice interface
that looks like it belongs on the OS with all of the other apps. (:

Point conceded that the most important thing is that your app does
something useful. And you'll never hear me argue, ever, that Apple
follows their own HIG with high consistency. What I'm referring to has a
lot to do with small details in layout and behavior that do not make an
app any less useful; Azureus is the only bittorrent client I use, and
the interface, though sometimes imperfect in its rendering, does not get
in my way in any significant manner. But it remains a fact that the
differences *are* noticeable, at least in the Java applications I've
used.

Ultimately, I brought up RubyCocoa not because I thought it would be
useful in JRuby, but because it was useful for me and it hadn't been
mentioned yet so far. JRuby and RubyCocoa/MacRuby really fill entirely
different needs. RubyCocoa was very useful for me as someone who needed
to make an application which called native OS X APIs*, but who only knew
Ruby, not Objective-C. I wouldn't ever use it to make a cross-platform
application, any more than I would use the ruby-win32 api for a
cross-platform application. That's not the point of having it.

*For reference, the things RubyCocoa allowed me to do were: registering
for NSWorkspace notifications to nicely handle not bugging the user if
the reason the application is being quit is because the user is logging
out (among other things); save user preferences using the NSUserDefaults
API and thus be able to manage those prefs via WorkGroup Manager (not
that I'm currently doing so, but I now could); add auto-updating
functionality via the Sparkle framework; use Interface Builder to create
the UI (say what you will, I really like Interface Builder as a tool);
define a dynamic dock menu. Some of these things undoubtably would have
been possible without directly calling Objective-C APIs. With RubyCocoa,
none of these were not only possible, they were fairly *easy*, and I
don't even know Objective-C to begin with. Ultimately, it's a matter of
choosing the right tool for the job.
--
Posted via http://www.ruby-forum.com/.

.