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
On 2/17/06, [email protected] [email protected] wrote:
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
On Saturday 18 February 2006 12:49 pm, Wilson B. wrote:
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
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
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?
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.
On Saturday 18 February 2006 01:08 pm, [email protected] wrote:
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
On Saturday 18 February 2006 02:21 pm, Scott W. wrote:
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
On 2/18/06, [email protected] [email protected] wrote:
guidelines, Dentrix is another great example for having a decent mouse based
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.
( 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.
On 2/18/06, Tsume [email protected] wrote:
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?
On 2/18/06, Gregory B. [email protected] wrote:
didn’t work. Tsume to the rescue, aka. Wonder Boy!
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.
On Sat, 2006-02-18 at 18:11 +0900, Gregory B. wrote:
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
On Sat, 2006-02-18 at 23:23 +0900, Gregory B. wrote:
didn’t work. Tsume to the rescue, aka. Wonder Boy!
You haven’t peeked at the database… have you?
Well, no. Supposedly its huge. I probably shouldn’t look.
Tsume
On Feb 18, 2006, at 11:12 AM, Tsume wrote:
You haven’t peeked at the database… have you?
Well, no. Supposedly its huge. I probably shouldn’t look.
I would sure look before I paid them any more money. I worked on a
project where we had to dig into the database layer of Dentrix. It’s
easily the worst designed database I’ve every encountered, and that’s
really saying something.
Just a random example off the top of my head: The last 20 payments
for an account are all stored in a single field as just a long string
of digits (hex encoded, if memory serves). Dentrix goes to
extraordinary lengths like this to destroy all value gained from
using a database backend in the first place. (Querying their
database structure for anything meaningful is more or less impossible.)
If you don’t want to go that far, just hook up a program that let’s
you watch its queries flow by. The software easily issues 20 to 50
queries for each one it should need. It’s downright scary to watch
it work.
I’m 100% confident scary errors lurk in that codebase.
Giving these people money is a very brave act. Trusting their
software is much worse. 
James Edward G. II
On Sat, 2006-02-18 at 23:25 +0900, Gregory B. wrote:
chart someones mouth, they were freaking out when right click, chart
didn’t work. Tsume to the rescue, aka. Wonder Boy!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
On 2/18/06, Tsume [email protected] wrote:
entered by the receptionist. When there were dental assistants trying to
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.
Agreed. Dentrix is pretty straightforward, I just hate the way it
looks. On top of that there are little weird annoying things that we
need to do that might be specific to us, but we’ve had to hack around
to get daysheets printing the way we want, to get Appointments showing
at all sorts of weird intervals, etc… On the reporting side of
things, there are some painful aspects.
Anyway, Dentrix is definitely not a ruby topic, so feel free to reply
off list if you’d like.
On Sun, 2006-02-19 at 06:27 +0900, Scott W. wrote:
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.
You must deal with the most stupid people of the world then. I’m talking
about normal people. They want an interface which is wizard like. Theres
a reason why Jasc Imaging software, some digital imaging wizard, not the
editor which was such a breeze to use when I slapped it right in front
of a user, its because of the wizard like interface.
Also, you are right about one comment. Windows users won’t know how to
operate MacOSX apps right off, but can learn. MacOSX has a very
different concept of how the windowing system work, also with 1) file
chooser 2) treelist/viewlist. I’m talking about using the toolkit’s
basic widgets which are compatible across any system. If I were to write
an application for cross compatibility, I would for one not use the
MacOSX tree widget with a plus/minus button underneath. I’d construct my
own system which is easy to users, or a popup window with a wizard when
you add “something”. Its up to the programmer, not the toolkit.
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).
An app is an app. I’ve seen useful and easy to use applications on
MacOSX without using the Aqua toolkit. Using the native widgets is only
a convenience, not a rule. XChat is completely usable under MacOSX, just
not pretty. Look is a convenience not a rule. Convenience doesn’t the
application work to make money. Badly designed applicatoins will loose
money. 2 different topics. The macosx application being slapped on to
users isn’t a good comparison because previously stated MacOSX
applications are completely different in how the system works.
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.
Tk is just fine, with use of Tile, but maybe you didn’t see this thread,
or the other similar thread which I replied about Tk/Tile for use with
native widgets on the windows platform. Another good candidate would be
to use Gtk. However when using toolkits on MacOSX, Tk(with tile, except
on MacOSX(TkAqua) is probably the best choice for portability. Its up to
the user to design a good inteface.
Tsume
I’m not interested in a flame war over interface design but I do want
to point out something:
You must deal with the most stupid people of the world then. I’m
talking
about normal people.
If there’s anything I’ve learned it’s that end users, even technically
literate ones, need all the help they can get. They are not “stupid” as
such but they certainly can’t be expected to be even proficient at
operating a computer. Any step that takes a person farther away from
what they expect damages their ability to use my software. If someone
downloads a free trial and it “feels weird” or “looks funny” or doesn’t
perform as they expect it too then that’s money out of my pocket,
regardless of my opinion of their intelligence or how trivial I think
the difference is between how my app works and what they expect.
Like I said earlier though, this sort of thing only applies to
“shrinkwrap” style applications. Large industry specific apps and in
house developed applications don’t have the same requirements.
On 18/02/2006, at 5:05 PM, [email protected] wrote:
On Saturday 18 February 2006 02:21 pm, Scott W. wrote:
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.
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.
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.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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs