Desktop apps written in Ruby?

[petermichaux]

Hi,

I've only used Ruby in the Rails framework. How about using Ruby to
build desktop apps with fancy drag and drop GUI with directory trees
and tabbed panes etc. Can such an app be developed as easily or easier
than with Java/Swing?

It looks like Tk is used for Ruby GUI. Is Tk as advanced as Swing?

What sort of desktop app frameworks are their for Ruby?

Thanks,
Peter

 

[Wilson Bilkovich]

Hi,

I've only used Ruby in the Rails framework. How about using Ruby to
build desktop apps with fancy drag and drop GUI with directory trees
and tabbed panes etc. Can such an app be developed as easily or easier
than with Java/Swing?

It looks like Tk is used for Ruby GUI. Is Tk as advanced as Swing?

What sort of desktop app frameworks are their for Ruby?

GTK and Qt are the most feature-rich Ruby-compatible frameworks, but
there are many others (wxWidgets, Fox, Tk, etc.)
Ruby/Qt even has a nice book now:
http://www.pragmaticprogrammer.com/titles/ctrubyqt/index.html

 

[petermichaux]

Thanks for the reply. From that QTRuby link "to create cross-platform
GUI applications for Linux and OS X in Ruby". Unfortunately I will need
to support Windows XP. Sounds like QTRuby can't do that. True?

Peter

 

[tsumeruby]

GTK and Qt are the most feature-rich Ruby-compatible frameworks, but
there are many others (wxWidgets, Fox, Tk, etc.)
Ruby/Qt even has a nice book now:
http://www.pragmaticprogrammer.com/titles/ctrubyqt/index.html

The toolkits are feature complete yes, but what matters is how frozen and
stable each is for programming. ruby/tk is by far the most frozen and mature.
ruby-gtk2 is frozen as well. qtruby's usage seems to be in a state of flux,
but is stable to use. Others really don't match up due to base toolkit
version which is bound doens't have UTF availability, frozen API, or
incomplete bindings.

Tsume

 

[tsumeruby]

Thanks for the reply. From that QTRuby link "to create cross-platform
GUI applications for Linux and OS X in Ruby". Unfortunately I will need
to support Windows XP. Sounds like QTRuby can't do that. True?

Peter

Unfortunately, there isn't a stable windows build, they've been working on it.
I believe you should just use ruby-gtk, or ruby/tk(with tile. makes native
widgets with tk) More information about Tile in the following email to
ruby-talk.

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/180329

I described just about all the important facts about Tk, and would be an
excellent choice if you can learn to use the API efficiently.

I've used FOX, and even used fxruby for a very long time. There are great
downfalls which made me use another toolkit. FOX is useless to me for having
no decent UTF support, even though the support is slowly coming along.
Ruby/GTK2 would be a good solution, especially if you're going to run the
applications on unix, scim-gtk2-immodule is _very_ useful. I use GNOME, so
creating GTK/GNOME based apps over Tk is a plus for me.

Tsume

 

[tsumeruby]

Why not just build the front end of the app in a windows language
(C++,VB,...) and then expose the APIs so that you can build the
business logic in Ruby?

Well, you are welcomed to use the Windows C API to build your applications,
however designing the application might be a task.

Honestly as good as Ruby is for so many things it's not the language to
be building GUI's in. TK and QT etc... always feel clunky compared to
native windows or mac apps. I know there's a Ruby- Objective C bridge
for the Mac but I don't know what's available for windows.

Many developers writing software for other operating systems feel the APIs
used to write GUI based software with GTK, QT, and Tk are very suitable. Of
course people care about look, but if look is so important you want to
capture the exact feel, then the programmer should be using the
supported/managed languages for the specified OS. Windows would be using
the .NET languages. On MacOSX Objective-C, the application language, should
be used to write software. However, users don't expect native look, they
expect a easy to use interface. Sure, you've read the articles on how making
your own pixmap GUI interface renders the program useless, but only because
people have been writing about the interfaces which fail. The only person who
is accountable for making a bad interface is the programmer itself. There are
several pixmaps interfaces which work very well. I know printers now have the
LCD when you want to perform some task, those are well designed GUI
interfaces. There is the Jasc photo imaging software meant for the user,
TheraWriter.PT is another good example which doesn't use standard GUI
guidelines, Dentrix is another great example for having a decent mouse based
interface to describe the teeth of a patient. Native look has absolutely
nothing to do with making a good application, just a convenience. Even using
a toolkit like WideStudio, a good application interface may be created. I
believe many programmers try blame the software on bad interfaces, when the
one accountable is the programmer itself.

Tsume

 

[Gregory Brown]

guidelines, Dentrix is another great example for having a decent mouse ba= sed
interface to describe the teeth of a patient.

Teeth sure. Everything else... forget it!

Dentrix looks like newspaper shavings and toothpaste and oil mixed together=

 

[Tsume]

Teeth sure. Everything else... forget it!

Dentrix looks like newspaper shavings and toothpaste and oil mixed together.
( We've got a C#/Ruby frontend to our Dentrix database backend to
spare our clients the pain that is Dentrix )

In fact... some of that is what Ruport is designed for. Reporting on
dentrix / dx1 crud.

What pain have you had with Dentrix? Did it drill a hole in the users
heads? The interface looks rather nice and easy to use, also the third
party software for the xray machine works wonders, which works very well
with dentrix. The only part I dislike about dentrix is the restriction
for ease of use is demolished if the patient information has not been
entered by the receptionist. When there were dental assistants trying to
chart someones mouth, they were freaking out when right click, chart
didn't work. Tsume to the rescue, aka. Wonder Boy!

Tsume

 

[Gregory Brown]

What pain have you had with Dentrix? Did it drill a hole in the users
heads? The interface looks rather nice and easy to use, also the third
party software for the xray machine works wonders, which works very well
with dentrix. The only part I dislike about dentrix is the restriction
for ease of use is demolished if the patient information has not been
entered by the receptionist. When there were dental assistants trying to
chart someones mouth, they were freaking out when right click, chart
didn't work. Tsume to the rescue, aka. Wonder Boy!

You haven't peeked at the database... have you?

 

[Tsume]

You haven't peeked at the database... have you?

Well, no. Supposedly its huge. I probably shouldn't look.

Tsume

 

[Tsume]

Also, to keep this more on topic... (about GUIs) the appointment
schedules are kind of awkward and just don't really fit our needs
well. It's easy enough to integrate with it (with some pain), so I
suppose that's a good thing.

Huh? Well Dentrix Appointment works better than Office Hours. They use
the overcomplicated rubbish downstairs. Office Hours is a good example
over what I was talking about. NDC uses native widgets, but just a
horrible overcomplicated design. People keep switching the views from
master to single rows, which is a completely pointless feature. I
haven't had any problems with dentrix appointment, because the interface
is simple. Its like comparing Windows to MacOSX/or GNOME. People really
need to use the KISS method.

Tsume

 

[Scott Weeks]

Well, you are welcomed to use the Windows C API to build your
applications,
however designing the application might be a task.

How is this so? I'm not a windows developer and I've only done a few
things in VC++ but the "physical" design of the application is a breeze
compared to juggling everything else (message passing and whatever
other strange beasts lie beneath the surface). I was hypothetically
speaking though as far as using Ruby as a backend. I tried it for one
particular application and it was a bear to try to handle windows
messages appropriately.

I also tried the Ruby Cocoa bridge for OS X about a year and a half ago
but I couldn't quite get that to do what I wanted it to.

However, users don't expect native look, they
expect a easy to use interface.

This is dead wrong.

I really don't mean to be inflammatory but users care very much about
consistency. In fact consistency is probably the are with the greatest
effect on the outcome when designing user interfaces. If you were to
magically drop a well designed Cocoa application in the middle of a
Windows environment it would confuse the hell out of users, no matter
how well it was engineered for usability.

However, if you are building an internal corporate app then it doesn't
matter too much because people can be trained to use and accept
whatever they are given. In that case it's generally better to optimise
for developer time than to optimise for user experience.

As well Windows users are more used to pain so they are more forgiving
when it comes to non-native interfaces. I do know that Mac apps that
aren't native stick out like dogs balls and there is very little chance
people will go near them (the sole exception that I can think of is
Firefox).

It (like anything else) depends on the task at hand, and I certainly
don't mean to come off in the wrong way. I just think it deserves a bit
of reflection and I really think that GUI development in Ruby could be
amazing if the proper bridges were built to native systems rather than
just being Yet Another Language with TK support.

Cheers,
Scott