The definitive GUI for Ruby

Hello there.

I'm wondering about some things here.

Everytime I talk about Ruby to programmers of other languages, they ask "but
what is the Ruby official GUI?".

Ok, I know that we have some really good options on GUIs - GTK, Qt, etc, and we
use the one we like most - but this kind of freedom sometimes can looks like a
missing "way to do that", at least for the biggest part of those guys, and, let
me confess, sometimes I stay confused about this question also, because there
are really good choices and no time available to test it all.

I'll make some apps and I'm still with doubts about what option to use!

I'm just wondering if will not be a good (or horrible!) idea to have an
"official" Ruby GUI (not Tk, please! some more cute components :wink: to make clear
to people what can be their first option to use when migrating their apps from
some other language. As Rails is *the* Ruby option for web development, I think
the apps GUI is still some kind of losing the focus ...

What you guys think about? What could be our answer to that initial question?

Best regards,

- --
- ----------------------------
Eustáquio "TaQ" Rangel
eustaquiorangel@yahoo.com
http://beam.to/taq
Usuário GNU/Linux no. 224050

* Eustaquio Rangel de Oliveira Jr. <eustaquiorangel@yahoo.com> [2005-10-04 07:52]:

I'm wondering about some things here.

Everytime I talk about Ruby to programmers of other languages,
they ask "but what is the Ruby official GUI?".

What you guys think about? What could be our answer to that
initial question?

    http://engrm.com/wiki/Refresh

    Cheers.

···

--
Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/

No. Rails isn't the "the" Ruby option for web development. It is _a_ Ruby
option for web development. It's success has come about largely because of
DHH's hard work, time, and marketting perseverance on a capable product.
It's not the only choice, though, or even necessarily the best, depending on
one's needs.

The situation with GUI frameworks is similar. There are pros and cons with
every one of them, so the choice of GUI depends on one's goals. An official
GUI for Ruby would be a bad idea, just as an official web development
framework for Ruby would be a bad idea. Better would be a good,
comprehensive, relatively impartial summary of Ruby GUI options, perhaps with
runnable examples available for download, so that the GUI framework landscape
is clearer.

There are a couple pages on the rubygarden.org wiki about this. The most
complete one that I know of is

But it stops short of what, IMHO, would be ideal for a one stop Ruby GUI
options reference.

Kirk Haines

···

On Tuesday 04 October 2005 5:51 am, Eustaquio Rangel de Oliveira Jr. wrote:

I'm just wondering if will not be a good (or horrible!) idea to have an
"official" Ruby GUI (not Tk, please! some more cute components :wink: to make
clear to people what can be their first option to use when migrating their
apps from some other language. As Rails is *the* Ruby option for web
development, I think the apps GUI is still some kind of losing the focus
...

Everytime I talk about Ruby to programmers of other languages, they ask "but
what is the Ruby official GUI?".

There's no such thing, and that's a good thing.

I'm just wondering if will not be a good (or horrible!) idea to have an
"official" Ruby GUI (not Tk, please! some more cute components :wink: to make clear
to people what can be their first option to use when migrating their apps from
some other language. As Rails is *the* Ruby option for web development, I think
the apps GUI is still some kind of losing the focus ...

Sorry, but Rails is not "the" option or even the "official" option.
Rails just happens to be the most popular option. I'm sure that Kirk
Haines and George Moschovitis and anyone else who works on web
application frameworks would *love* to hear that Rails is officially
the Ruby web framework. It might even surprise DHH.

What you guys think about? What could be our answer to that initial question?

"Ruby doesn't have one, because it doesn't need one. If you're
developing for MacOS X, you need Cocoa. Ruby does that. Ruby also
supports native Windows MFC development and Qt and Gtk as well."

-austin

···

On 10/4/05, Eustaquio Rangel de Oliveira Jr. <eustaquiorangel@yahoo.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

As somebody who's much more "a serious user who programs small things" rather than a professional programmer, and a Mac user, I can tell you now that any app that tried to get me to use some generic GUI instead of using Aqua is an app I wouldn't use. GUI design is all about everything being exactly where it's supposed to be. Buttons that work they way they always work. Menus where "File," "Help" and so on are in the same place, and do the same things, every time.

A "universal" GUI could get close, but getting close just means it'll be insanely annoying because of the little things that aren't exactly right.

Languages don't get to have "official" GUIs. That's the OS's prerogative these days.

···

On Oct 4, 2005, at 4:51, Eustaquio Rangel de Oliveira Jr. wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello there.

I'm wondering about some things here.

Everytime I talk about Ruby to programmers of other languages, they ask "but
what is the Ruby official GUI?".

* Eustaquio Rangel de Oliveira Jr. <eustaquiorangel@yahoo.com> [2005-10-04

07:52]:

> Everytime I talk about Ruby to programmers of other languages,
> they ask "but what is the Ruby official GUI?".
>
> What you guys think about? What could be our answer to that
> initial question?

    http://engrm.com/wiki/Refresh

Now, be fair. Refresh looks like it has some admirable goals, but it is still
vapor. It is not yet even a valid choice for a GUI framework, let alone one
that has a chance to rise to prominence.

Kirk Haines

···

On Tuesday 04 October 2005 6:05 am, Alan Gutierrez wrote:

No. Rails isn't the "the" Ruby option for web
development. It is _a_ Ruby
option for web development. It's success has come
about largely because of
DHH's hard work, time, and marketting perseverance
on a capable product.
It's not the only choice, though, or even
necessarily the best, depending on
one's needs.

Well, you got the idea. :slight_smile: I was talking about all
the hype about Rails. We have a well-know and good
product to talk about at least on a first moment. So
people can say "oh, I heard about it".

Later, when we started the talk with a common know
product, we can talk about the other ones.

There are a couple pages on the rubygarden.org wiki
about this. The most
complete one that I know of is
http://rubygarden.org/ruby?ComparingGuiToolkits

Thanks for the URL.

Best regards,

···

--- Kirk Haines <khaines@enigo.com> wrote:

----------------------------
Eustáquio "TaQ" Rangel
eustaquiorangel@yahoo.com

Usuário GNU/Linux no. 224050

I answered Kirk right now. :slight_smile:
Sorry if I was not clear, I was just trying to mention
all the hype about Rails and as it is a well know
product these days.

Not that I consider it the best web framework. I can't
talk about that, I never used any of the options
available.

Best regards,

···

--- Austin Ziegler <halostatue@gmail.com> wrote:

Sorry, but Rails is not "the" option or even the
"official" option.
Rails just happens to be the most popular option.
I'm sure that Kirk
Haines and George Moschovitis and anyone else who
works on web
application frameworks would *love* to hear that
Rails is officially
the Ruby web framework. It might even surprise DHH.

----------------------------
Eustáquio "TaQ" Rangel
eustaquiorangel@yahoo.com

Usuário GNU/Linux no. 224050

A "universal" GUI could get close, but getting close
just means it'll
be insanely annoying because of the little things
that aren't exactly
right.

Millimeter stuff. :slight_smile:

Languages don't get to have "official" GUIs. That's
the OS's
prerogative these days.

I don't agree with that. Java have Swing.
And some others, right, but people focus on it. Does
not means it's perfect, but it's the focus there. And
use to work fine on a lot of OS's.

I mean, maybe not a sooooo official (for programmer,
for Sun it is), but is a start point.
Tk is still too ugly for make programmers that are
migrating. :slight_smile:

Best regards,

···

--- Dave Howell <groups@grandfenwick.net> wrote:

----------------------------
Eustáquio "TaQ" Rangel
eustaquiorangel@yahoo.com

Usuário GNU/Linux no. 224050

Well, actually, you use non-Aqua GUIs all the time. Every web site
offers an unknown combination of HTML, image maps, AJAX, etc. That
said, I agree that having consistent look and feel on the desktop is
very useful.

You may be interested to know about

  RubyCocoa - A Ruby/Objective-C Bridge for Mac OS X with Cocoa
  RubyCocoa - Documentation

RubyCocoa seems to be an active project, so I presume that it actually
lets Ruby coders produce Cocoa apps, using the Interface Builder, etc.
My experience with CamelBones (which does the same sort of thing for
Perl) leads me to suspect that the experience is not seamless:

   * Objective-C has its own naming conventions and method invocation
      syntax, which are quite different from those used by Ruby, Python,
      etc. In CamelBones, this means that the programmer has to look up
      methods by "translated" names, etc.

   * Apple hasn't shown any great interest in supporting any languages
      other than Objective-C for Cocoa programming. They wave a hand in
      the direction of Java, from time to time, but ObjC is definitely
      the "blessed" language.

   * CamelBones ran into problems when the version of Perl changed. I
      don't know if RubyCocoa has similar "robustness" issues.

I would be happy to hear comments from any RubyCocoa users, as I've been
considering trying it out at some point...

-r

···

At 6:58 PM +0900 10/5/05, Dave Howell wrote:

... any app that tried to get me to use some generic GUI instead
of using Aqua is an app I wouldn't use. ...

--
email: rdm@cfcl.com; phone: +1 650-873-7841
http://www.cfcl.com - Canta Forda Computer Laboratory
http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.

follow to convert from OC to Ruby. For example, from the tutorial:

  [oPanel runModalForDirectory:self file:nil types nil]

becomes

  oPanel.runModalForDirectory_file_types(self, nil, nil)

"The other technique can be used to make a little more sense of method
names that are extremely long. Using this technique, the method name
consists of everything in the Objective-C method's name up to the
first detached parameter name. The rest of the parameter names are
moved into the argument list. Thus, every argument after the first is
prefaced with another argument that is a Ruby symbol with the same
name as the parameter it represents. It sounds confusing, I know, but
the example below shows you how easy it is once you get used to the
syntax."

And, when standard calls return an NSArray or NSString, just use
#to_a and #to_s to convert them to ruby.

···

On 10/5/05, Rich Morin <rdm@cfcl.com> wrote:

You may be interested to know about

  RubyCocoa - A Ruby/Objective-C Bridge for Mac OS X with Cocoa
  RubyCocoa - Documentation

   * Objective-C has its own naming conventions and method invocation
      syntax, which are quite different from those used by Ruby, Python,
      etc. In CamelBones, this means that the programmer has to look up
      methods by "translated" names, etc.

From my limited experience, there is a straightforward pattern to
--
Jim Freeze

Yes, seems to be a very good idea, but it's really not
the example I was trying to find to tell people about
GUI. Maybe when it's ready. :slight_smile:

Best regards,

···

--- Kirk Haines <khaines@enigo.com> wrote:

Now, be fair. Refresh looks like it has some
admirable goals, but it is still
vapor. It is not yet even a valid choice for a GUI
framework, let alone one
that has a chance to rise to prominence.

----------------------------
Eustáquio "TaQ" Rangel
eustaquiorangel@yahoo.com

Usuário GNU/Linux no. 224050

* Kirk Haines <khaines@enigo.com> [2005-10-04 08:25]:

···

On Tuesday 04 October 2005 6:05 am, Alan Gutierrez wrote:
> * Eustaquio Rangel de Oliveira Jr. <eustaquiorangel@yahoo.com> [2005-10-04
07:52]:

> > Everytime I talk about Ruby to programmers of other languages,
> > they ask "but what is the Ruby official GUI?".
> >
> > What you guys think about? What could be our answer to that
> > initial question?
>
> http://engrm.com/wiki/Refresh

Now, be fair. Refresh looks like it has some admirable goals, but
it is still vapor. It is not yet even a valid choice for a GUI
framework, let alone one that has a chance to rise to prominence.

    It's a week old, if that's what you mean. :slight_smile:

    Seriously, I'm just letting people know in care they're
    interested.

    Cheers.

--
Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/

Eustaquio Rangel de Oliveira J wrote:

···

--- Kirk Haines <khaines@enigo.com> wrote:

No. Rails isn't the "the" Ruby option for web
development. It is _a_ Ruby
option for web development. It's success has come
about largely because of
DHH's hard work, time, and marketting perseverance
on a capable product.
It's not the only choice, though, or even
necessarily the best, depending on
one's needs.

Well, you got the idea. :slight_smile: I was talking about all
the hype about Rails. We have a well-know and good
product to talk about at least on a first moment. So
people can say "oh, I heard about it".

Later, when we started the talk with a common know
product, we can talk about the other ones.

There are a couple pages on the rubygarden.org wiki
about this. The most
complete one that I know of is
http://rubygarden.org/ruby?ComparingGuiToolkits

Is it possible to add a table with feature vs. UI toolkit so people can
quickly check them against each other?

    robert

Eustaquio Rangel de Oliveira J wrote:

Tk is still too ugly for make programmers that are
migrating. :slight_smile:

Tk is only ugly if that's the way you like it. You have a
full set of themed widgets available now that give you
native look and feel, with all the same dynamic control and
general ease of use that Tk has always provided. All this
on Aqua, Win32 and X11 (even Windows/CE). Some screenshots
of Tk apps that try not to be ugly:

The Perl Dev Kit and Tcl Dev Kit UIs:

Tk on Win/CE (I know that the Perl/Tcl::Tk use this too):

Coccinella:
http://hem.fyristorg.com/matben/
http://hem.fyristorg.com/matben/examples/index.html

An installer builder:
http://installbase.sourceforge.net/screenshots.shtml

An example of improving a Tk app by "going native":

···

--
   Jeff Hobbs, The Tk Guy
   http://www.ActiveState.com/, a division of Sophos

You may be interested to know about

  RubyCocoa - A Ruby/Objective-C Bridge for Mac OS X with Cocoa
  RubyCocoa - Documentation

   * Objective-C has its own naming conventions and method invocation
      syntax, which are quite different from those used by Ruby, Python,
      etc. In CamelBones, this means that the programmer has to look up
      methods by "translated" names, etc.

From my limited experience, there is a straightforward pattern to
follow to convert from OC to Ruby. For example, from the tutorial:

  [oPanel runModalForDirectory:self file:nil types nil]

becomes

  oPanel.runModalForDirectory_file_types(self, nil, nil)

Or alternatively:
oPanel.runModalForDirectory(self, :file, nil :types, nil]

which I think is often clearer and preserves the parameter type (recorded as a symbol) by the actual parameter.

My limited experience has been that RubyCocoa is very easy to use and there isn't much to learn to map between the ruby and objective c domains. Getting to grips with Cocoa is much harder but at least with RubyCocoa all the memory management headaches go away.

Dave.

···

On 5 Oct 2005, at 21:17, Jim Freeze wrote:

On 10/5/05, Rich Morin <rdm@cfcl.com> wrote:

"The other technique can be used to make a little more sense of method
names that are extremely long. Using this technique, the method name
consists of everything in the Objective-C method's name up to the
first detached parameter name. The rest of the parameter names are
moved into the argument list. Thus, every argument after the first is
prefaced with another argument that is a Ruby symbol with the same
name as the parameter it represents. It sounds confusing, I know, but
the example below shows you how easy it is once you get used to the
syntax."

And, when standard calls return an NSArray or NSString, just use
#to_a and #to_s to convert them to ruby.

--
Jim Freeze

... any app that tried to get me to use some generic GUI instead
of using Aqua is an app I wouldn't use. ...

Well, actually, you use non-Aqua GUIs all the time.

But my definition of "application" doesn't include web sites. Yours might. :slight_smile:

You may be interested to know about

RubyCocoa - A Ruby/Objective-C Bridge for Mac OS X with Cocoa

Actually, I've been using RubyCocoa for some months.

My experience with CamelBones (which does the same sort of thing for
Perl) leads me to suspect that the experience is not seamless:

  * Objective-C has its own naming conventions and method invocation
     syntax, which are quite different from those used by Ruby, Python,
     etc. In CamelBones, this means that the programmer has to look up
     methods by "translated" names, etc.

The developer came up with two different methods for mapping. I only learned one of them, because it's so easy.

To grab a random sample out of "Cocoa Programming for Mac OSX"
  - (void)drawAtPoint:(NSPoint)aPoint
    withAttributes:(NSDictionary *)attribs

should appear in Ruby as

  def drawAtPoint_withAttributes(aPoint, attribs)
    blah blah blah
  end

Interface Builder will 'magically' fill in ObjC skeletons for you in XCode, but you have to do that yourself in Ruby. Since that basically means that you don't get

  def YourObjectNameHere(something)
  end

typed for you, I really don't think that's too much of a loss. I am occasionally tripped up when I don't get a Cocoa object turned back into a Ruby one, but that's because it's _almost_ always handled by RubyCocoa.

RubyCocoa's still chasing some of the more recent and esoteric features. "Bindings" are not entirely smooth, and "Core Data" (from Tiger) depends on Bindings. But my background has been using XCode with AppleScript, and Ruby and RubyCocoa are doing much better than the AppleScript Studio support from Apple.

RubyCocoa does teach XCode do to syntactic coloring and procedural bookmarking and other stuff. Overall, I like it.

I would be happy to hear comments from any RubyCocoa users, as I've been
considering trying it out at some point...

Try rubycocoa-talk@lists.sourceforge.net. They're very nice and helpful, even when I've been rather grumpy and cross from being tortured by the installers for Ruby, RubyCocoa, Rails, RubyAEOSA, and RubyGems. I don't think I"ve ever had a Ruby[whatever] install itself smoothly the first time, with the single exception of whoever created the Ruby 1.8.2 installer that uses the Mac's own installation system. That, thank the stars, actually worked right the first time.

···

On Oct 5, 2005, at 10:47, Rich Morin wrote:

At 6:58 PM +0900 10/5/05, Dave Howell wrote:

Very good idea.

Best regards,

···

--- Robert Klemme <bob.news@gmx.net> wrote:

Is it possible to add a table with feature vs. UI
toolkit so people can
quickly check them against each other?

----------------------------
Eustáquio "TaQ" Rangel
eustaquiorangel@yahoo.com

Usuário GNU/Linux no. 224050

One feature I'd like to see mention is the ability for the UI toolkit
library to be embedded in binary distribution, like rubyscript2exe and a
few others do. I know wxruby plays well with rubyscript2exe but not Tk,
and for me that rules Tk out. I don't know about the other and it would
be nice to know.

Guillaume.

···

On Tue, 2005-10-04 at 22:41 +0900, Robert Klemme wrote:

>> There are a couple pages on the rubygarden.org wiki
>> about this. The most
>> complete one that I know of is
>> http://rubygarden.org/ruby?ComparingGuiToolkits

Is it possible to add a table with feature vs. UI toolkit so people can
quickly check them against each other?

--- Jeff Hobbs <jeffh@removethis.activestate.com>
wrote:

Eustaquio Rangel de Oliveira J wrote:
Tk is only ugly if that's the way you like it. You
have a
full set of themed widgets available now that give
you
native look and feel, with all the same dynamic
control and
general ease of use that Tk has always provided.
All this
on Aqua, Win32 and X11 (even Windows/CE). Some
screenshots
of Tk apps that try not to be ugly:

An example of improving a Tk app by "going native":
Going Native with Komodo's GUI Builder

Oh boy, was me that did not checked all its features
or Tk has evolved a lot on the last years? Will take a
look on all that stuff.

Thanks a lot for the links, Jeff. I hope you didn't
get the "ugly" thing as an insult.

Best regards,

···

----------------------------
Eustáquio "TaQ" Rangel
eustaquiorangel@yahoo.com

Usuário GNU/Linux no. 224050