"Why I Program In Ruby (And Maybe Why You Shouldn't)"

[Brian Adkins]

I don't think Rails is "the
gateway drug to Ruby".

It was mine. I now very much like Ruby for its own sake, but Rails
brought me to the party.

That's demeaning to both Rails and Ruby, for one
thing. For another thing, I don't believe for a minute that a team of
people as talented as the people who built Rails couldn't duplicate it
and its success or even improve upon it in *any* language.

I respectfully disagree. Other languages, yes, *any* language, no. Of
course, you and I may differ on the meaning of "success".

 

[Jari Williamsson]

3.) No clue about QT. (Somebody?)

I believe QT would be a no-no in the default Ruby distribution, due to
the license agreement.


Best regards,

Jari Williamsson

 

[Jari Williamsson]

Let's not forget the option of using Java GUI toolkits like Swing or
SWT with JRuby, either.

So which of these GUIs should be included in the standard Ruby
distribution, which was the OP's point?


Best regards,

Jari Williamsson

 

[MonkeeSage]

I believe QT would be a no-no in the default Ruby distribution, due to
the license agreement.

Best regards,

Jari Williamsson

Trolltech actually have a dial-license (alternate GPLv2) for non-
commerical uses. [1] But I wasn't suggesting proposals for core
library packages (I don't really think that Tk should be in core). I'm
just trying to list the available options for major, cross-platform
toolkits. I believe that ruby as a GUI glue language (it is *much
more* than glue, but it is *at least* glue), shouldn't focus on
distributing GUI toolkits or bindings as part of the standard library;
instead, it should be up to the developer to redistribute or make
accessible those requirements. For example, when an XP user downloads
a .NET2 and and only has .NET1 installed, there is no magical genie
that pops out of the app and says "poof, be installed--you now
have .NET2 *fireworks and party favors*" Instead, they are directed to
windows update to get the required software (or else it's bundled as a
redist and starts a separate install process). I see no reason for
ruby to be different. (Sorry...this is not directed at you at all
Jari, I'm just voicing my stream-of-consciousness. I thank you for
your input!).

[1] http://trolltech.com/products/qt/licenses/licensing/opensource/

Regards,
Jordan

 

[MenTaLguY]

So that's 5 major toolkits (or 6 if you count pure Swing, but I don't
know to what extent it implements native widgets; I think it's kind of
got its own look/feel and themes)...at *least* three of which are
production quality and support native look and feel across platforms
(SWT, WxWidgets, GTK).

In terms of look and feel, Swing is at least as "native" as Gtk is; both
use theme engines rather than wrapping actual native widgets. The main
difference is that GTK normally defaults to a theme emulating the native
look and feel, whereas most distributions of Swing (except the bundled
one on OS X) do not. It's easy to force Swing to use the native look
and feel though:

require 'java'
UIManager = Java.javax.swing.UIManager
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName)

...the last line of which you could also write:

UIManager.look_and_feel = UIManager.system_look_and_feel_class_name

(This IS Ruby, dammit.)

One other advantage of Swing over Gtk is the OS X support -- on OS X,
if the com.apple.macos.useScreenMenuBar runtime property is set to
true your application will use the system menu bar for menus, which is
not (as far as I know) yet possible with Gtk.

One downside to Swing on Windows is that the native Win32 theme lacks
some refinement (mostly odd padding choices), although Java 7 promises
to improve that situation.

-mental

 

[MenTaLguY]

So which of these GUIs should be included in the standard Ruby
distribution, which was the OP's point?

I'm not sure any of them need to be in the standard distribution
(most languages don't have GUI toolkits there), but it is important
that they be readily available without a painful build process.

-mental

 

[MonkeeSage]

In terms of look and feel, Swing is at least as "native" as Gtk is; both
use theme engines rather than wrapping actual native widgets. The main
difference is that GTK normally defaults to a theme emulating the native
look and feel, whereas most distributions of Swing (except the bundled
one on OS X) do not. It's easy to force Swing to use the native look
and feel though:

require 'java'
UIManager = Java.javax.swing.UIManager
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName)

..the last line of which you could also write:

UIManager.look_and_feel = UIManager.system_look_and_feel_class_name

(This IS Ruby, dammit.)

One other advantage of Swing over Gtk is the OS X support -- on OS X,
if the com.apple.macos.useScreenMenuBar runtime property is set to
true your application will use the system menu bar for menus, which is
not (as far as I know) yet possible with Gtk.

One downside to Swing on Windows is that the native Win32 theme lacks
some refinement (mostly odd padding choices), although Java 7 promises
to improve that situation.

-mental

Nice. I've only played a little bit with JRuby, no GUI stuff, just
basics (my work is non-technical, so I've only used Java/Jruby/and
lately Scala as a hobby); other than that, I haven't run any Java apps
for quite some time. I just remembered a purple-ish sort of UI akin to
old macs (mac 7 or 8?).

UIManager.look_and_feel = UIManager.system_look_and_feel_class_name

I like how the setter is automatically initialized.

Regards,
Jordan

 

[Trollen Lord]

Note: parts of this message were removed by the gateway to make it a legal Usenet post.

Here are the four "big" toolkits and some infos:

2.) WxWidgets supports true native widgets. I know it supports native

Not on Vista anymore, where WPF is slowly beginning to be the standard.
WxWidgets is deterotiating at this moment pretty fast if compared to the
platform (which is developing).

Well, themeing is nice. It is not however the same as being genuinely
native. The looks is easy part but achieving the feel is extremely hard.
Some widgets simply always react slightly differently which bugs users even
though they don't always consciously notice it. That is why only native is
native.

4.) GTK+. Native installer (.msi/.exe), about 12 megs. Excellent ruby
bindings and documentation. The default theme on win* using a .dll to
render native widgets. Looks about 95% native and is comparably fast.
Some screentshots of GTK+ running on win xp show how it looks. [3][4]

The 5% is still on missing on XP as you pointed out as well. Anyways, it is
the "legacy" look (even most of the applications that target XP use newer
"Office" style looks etc) and sometimes fails to render properly (some
corporate environments for instance have group policies for unifying the
look of desktops, breaking the service that the native widgets feature of
gtk+/wimp requires. It falls back to default gtk in that case..) I'd say the
part that it handles natively is great, but it fails way too often.

So there is no shortage of cross-platform, native-look and feel

toolkits with ruby bindings. You just have to take the time and energy
to learn them.

I have known all those for years. The shortcomings make them appalling. Why
I even bother talking about this is that it is quite possible to make a sort
of toolkit that is used for telling "I want this sort of interaction" and
the toolkit selects the proper real native way to accomplish it. That would
be like holy grail of GUIs for Ruby.

Btw, QT never has attempted to blend in. You can theme the looks somewhat
but it feels on all but KDE desktops pretty weird. On top of that some
things are really hard to get right and those are at least the menus. Popups
and the main menus are quite different and irritating on QT.

 

[Trollen Lord]

Note: parts of this message were removed by the gateway to make it a legal Usenet post.

Good catch! And on that note, an app people may be familiar with is
azureus 2.5 [1] which has a native look and feel on all three major
platforms via SWT, which as mental said, is exposed through JRuby.

The newest Sun's jre actually calls native libraries to achieve most or at
least some. At least afaik. It should know at least GTK+ and windows forms
and changing between them is a matter of roughly 5 lines of code. You need
at least 1.6 though.

 

[Gerardo Santana Gómez Garrido]

I believe QT would be a no-no in the default Ruby distribution, due to
the license agreement.

You believe wrong.

Qt is dual-licensed. Trolltech offers free of charge a GPL licensed Qt.

 

[Trollen Lord]

Note: parts of this message were removed by the gateway to make it a legal Usenet post.

I'm not sure any of them need to be in the standard distribution
(most languages don't have GUI toolkits there), but it is important
that they be readily available without a painful build process.

I have to clarify. First of all, it was but one of my points, but one
nevertheless.

Now that is quite distinct question from whether it is a GOOD thing that
most languages don't have GUI toolkits there. We have been screwing up the
"art of programming" for couple decades already. Furthermore, how do you
define that "most languages". If you define it by "most used by amoutn of
programmers or applications at this moment", which seems more appropriate
then it becomes a battlefield of Delphi, Java and the .NET languages.

Build process is the engineering view imho. It is the "getting started using
something" process that you should worry about. Being tested (integration),
documented well, supported, fanboyed (perhaps even) is what you expect for
numerous positive reasons. Which means in other words: a plethora of
possibilities to build basic expected components of your platform you start
building on is really not as good as having something good by default. If
you went that way you'd be still happy programming in symbolic assembler or
so instead of Ruby. Like the article I referred to in my first post said:
Art. Focus on the programmer and feeling good. The present state does _not_
do that nor will.

Nor will slapping 1:1 bindings to some traditional single framework.

 

[MenTaLguY]

I like how the setter is automatically initialized.

There are a lot of niceties to JRuby's Java integration -- for
example, a method called #isSomePredicate is also accessible as
#some_predicate?, and (at least in 1.1) you can use a Ruby block
in lieu of a terminal argument whose type is any single-method
interface (e.g. Runnable). Java collections also implement
Ruby enumerable and so on.

Not that there aren't rough spots to work out yet, but we're
making a concerted effort to have Java libraries feel as "Ruby" as
possible.

-mental

 

[MonkeeSage]

[...snip...]

But you are complaining about the general state of affairs; not
anything ruby specific. As my posts demonstrated (I think) the ruby
toolkit bindings are on par with the state of the art; whether that
state is sufficient is another story. (And regarding Vista, that's
kind of a low-blow, as less than half of the XP apps even work
natively in Vista64, if at all). In any case, one is not without
recourse when it comes to x-platform GUI options in ruby. At least,
ruby is not behind any other language (including C) in this area,
because that's simply the state of the toolkits themselves. Toolkits
aren't Hellen Keller, and Ruby isn't the Miracle Worker. You can only
do so much with what you're given.

Regards,
Jordan

 

[Trollen Lord]

Note: parts of this message were removed by the gateway to make it a legal Usenet post.

But you are complaining about the general state of affairs; not
anything ruby specific. As my posts demonstrated (I think) the ruby
toolkit bindings are on par with the state of the art; whether that

Yes, BINDINGS are on par. However...

The state of the art? I'd say Shoes is that. It is dumb. Very dumb. But what
being dumb means is that there is a promise of separating the "this is what
I want" and "this is how I want to see it" from each other. It has been done
in other technologies like the web (html vs css) ages ago already and it has
major advantages. Shoes doesn't do it yet technically (nor ever will I
think?) but take a look at how you define the GUIs. It wouldn't be hard
removing the Cairo dependency and making it more dynamic. THAT is state of
the art and would make defining most of the GUIs a wonderful and Rubyish
process.

state is sufficient is another story. (And regarding Vista, that's

Yup.



kind of a low-blow, as less than half of the XP apps even work
natively in Vista64, if at all). In any case, one is not without

They do in Vista32. Which I am using at this moment. I don't have very many
things to complain about actually and have not bumped into even one single
application myself yet that would not have worked. But I think that is
irrelevant path to start discussing further. In any case, Vista seems to be
closer to 10% adoption rate and somewhere perhaps near 20% (just a quick
quess, although it is possible to estimate really accurately and reliably -
there are methods for that if you have complete marketing data from longer
period) there is the tipping point. After that it will be landslide. That
10% from roughly 1,3 billion computers is 130 millions already. We are not
talking small "markets" here in any case.

because that's simply the state of the toolkits themselves. Toolkits

aren't Hellen Keller, and Ruby isn't the Miracle Worker. You can only
do so much with what you're given.

I just have the feelign the entire approach is aged and there would be a
good moment for throughout sanity check.

 

[MonkeeSage]

There are a lot of niceties to JRuby's Java integration -- for
example, a method called #isSomePredicate is also accessible as
#some_predicate?, and (at least in 1.1) you can use a Ruby block
in lieu of a terminal argument whose type is any single-method
interface (e.g. Runnable). Java collections also implement
Ruby enumerable and so on.

Not that there aren't rough spots to work out yet, but we're
making a concerted effort to have Java libraries feel as "Ruby" as
possible.

-mental

A bit off-topic, but how does JRuby resolve that (i.e., the
convenience method resolution)? It is some AST magic, or something as
mundane as splitting camel-cased indentifier strings? (not to knock
the latter; if it works, it works). I'll have to digg into JRuby
againt next weekend. It's been three or four months since I last had a
gander.

"Keep on keepin' on"-in,
Jordan

 

[MenTaLguY]

Build process is the engineering view imho. It is the "getting started
using something" process that you should worry about.

That's what I'm getting at. For the most part, today, users have to
compile the library themselves if they want to use it. That's a pretty
high bar.

At least the Qt binding actually has a win32 gem, though everyone else
still has to compile from the .tgz. Ruby-gnome has... well, it's got
Debian packages. Actually building ruby-gnome from source is not a
fun experience.

Nor will slapping 1:1 bindings to some traditional single framework.

It'd be a distinct improvement, although it's not clear that any one
is suitable -- all the available frameworks involve considerable
tradeoffs. I do think that Swing with JRuby is the best option for GUI
programming with Ruby at the moment: if you have Java, it just works out
of the box. It's obviously not the final answer for Ruby as a whole
though, nor is it that pleasing to use.

If Shoes matures and gets the rough bits filed off, I think it could
be a solid contender for a ships-with-Ruby solution that's actually
fun. But right now Shoes is an experiment and we're still at the
stage of doing R&D to determine what sort of shape a good Ruby GUI
library has.

-mental

 

[MonkeeSage]

Note: parts of this message were removed by the gateway to make it a legal Usenet post.


Yes, BINDINGS are on par. However...

The state of the art? I'd say Shoes is that. It is dumb. Very dumb. But what
being dumb means is that there is a promise of separating the "this is what
I want" and "this is how I want to see it" from each other. It has been done
in other technologies like the web (html vs css) ages ago already and it has
major advantages. Shoes doesn't do it yet technically (nor ever will I
think?) but take a look at how you define the GUIs. It wouldn't be hard
removing the Cairo dependency and making it more dynamic. THAT is state of
the art and would make defining most of the GUIs a wonderful and Rubyish
process.

You might be interested in XULRunner [1] from the Mozilla foundation
(i.e., the dudes who make firefox). XUL is already a cross-breed
between markup and GUI, and works on the "big three" OS's as it comes.
It's actually very easy to use if you know HTML/XML. The main drawback
is that it requires JavaScript to drive it (inc. DCOM, XPCOM).
XULPlanet.com has in-depth documentation however. [2]. I have no
problem with JS, but some people hate it.

[1] http://developer.mozilla.org/en/docs/XULRunner
[2] http://xulplanet.com/

They do in Vista32. Which I am using at this moment. I don't have very many
things to complain about actually and have not bumped into even one single
application myself yet that would not have worked. But I think that is
irrelevant path to start discussing further. In any case, Vista seems to be
closer to 10% adoption rate and somewhere perhaps near 20% (just a quick
quess, although it is possible to estimate really accurately and reliably -
there are methods for that if you have complete marketing data from longer
period) there is the tipping point. After that it will be landslide. That
10% from roughly 1,3 billion computers is 130 millions already. We are not
talking small "markets" here in any case.

I don't question the market share! And obviously, monkey-makers like
WoW are going to be updated to work *no matter what* ("OMG! LOL!!
LOLZ!! PWNED!"). But apps of lesser importance like FileZilla FTP
Server, aren;t guaranteed to work. My point was simply this; you can't
use a relatively new platform to hold against toolkits that took years
to integrate with the old platform. The standard is still the old
platform, the new, is, well...new!

Regards,
Jordan

 

[Jeremy McAnally]

There is such a tool that I spent all summer writing, but very few
people use it.

It's called dcov (rcov for documentation).

http://dcov.rubyforge.org

Of course, ironically, it's poorly documented, but you can still use
it just with little customization.

--Jeremy

I agree with lots of what you said, and I think much of it can be
because many might think of Ruby as a way to cut corners?

Why are there so few projects on Rubyforge that leave their alpha/beta
stages to Production/Stable? Why are there so few libs with really good
documentation? Why is there not even good documentation on how to create
a Gem or maintaining it with Hoe? Why are there so few documentation
packages that use anything other than the old frame-based default
template? And so on.

Anyway:
Is there a utility that analyzes the data that RDoc is processing for
documentation (or analyze the result)? It should scan for methods with
missing documentation, methods with missing examples, count
cross-references, etc, etc. If not, this is the challenge: to create
such a utility!
Developers should get help to spot weak documentation and it should be
possible to rate one's documentation and be able to say things like
"Documentation gets a 97% quality rating by <name of utility>"


Best regards,

Jari Williamsson

--
http://www.jeremymcanally.com/

My books:
Ruby in Practice
http://www.manning.com/mcanally/

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

 

[MonkeeSage]

It wouldn't be hard removing the Cairo dependency and making it more dynamic.

It actually would, since Cairo is full bitmap rendering suite...it
would involve implementing all the of the bit-bliting all over agin,
for one (very small) thing. Cairo is a general purpose screen drawing
library. Replacing/re-implementing it would be a *HUGE* (and
pointless) task.

Regards,
Jordan

 

[MenTaLguY]

A bit off-topic, but how does JRuby resolve that (i.e., the
convenience method resolution)? It is some AST magic, or something as
mundane as splitting camel-cased indentifier strings? (not to knock
the latter; if it works, it works).

It uses the Java reflection API to enumerate methods on Java classes
and splits camel-cased names to produce the "Ruby" versions. There
isn't any syntax magic required on the Ruby side of things.

I'll have to digg into JRuby againt next weekend. It's been three
or four months since I last had a gander.

I'll forewarn you that the Java integration portion of the code is
a bit pain-inducing. We're working towards a rewrite/cleanup though.

-mental