On Nov 26, 8:35 pm, “M. Edward (Ed) Borasky” [email protected]
wrote:
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”.
On Wed, 28 Nov 2007 03:30:00 +0900, MonkeeSage [email protected] wrote:
So there is no shortage of cross-platform, native-look and feel
toolkits with ruby bindings.
Let’s not forget the option of using Java GUI toolkits like Swing or
SWT with JRuby, either.
-mental
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.
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). And BTW, that deserves a giant THANK YOU to
all the folks who made the ruby bindings happen for those toolkits.
And while I’m thinking of it, just as big a thank you to the smaller
guys write the bindings for FOX and FLTK and other lesser known
toolkits (keep up the good work!).
I believe QT would be a no-no in the default Ruby distribution, due to
the license agreement.
Best regards,
Jari W.
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!).
On Wed, 28 Nov 2007 04:40:00 +0900, MonkeeSage [email protected]
wrote:
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:
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.
look and feel, whereas most distributions of Swing (except the bundled
-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?).
On Wed, 28 Nov 2007 04:55:31 +0900, Jari W. [email protected] wrote:
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.
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.
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.
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.
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.
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.
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.
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.
On Wed, 28 Nov 2007 05:51:51 +0900, “Trollen L.” [email protected] wrote:
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.
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.
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!
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.
a Gem or maintaining it with Hoe? Why are there so few documentation
possible to rate one’s documentation and be able to say things like
“Documentation gets a 97% quality rating by ”
On Wed, 28 Nov 2007 06:30:01 +0900, MonkeeSage [email protected]
wrote:
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.
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.
