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
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 2/17/06, petermichaux@yahoo.com <petermichaux@yahoo.com> wrote:
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?
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
On Saturday 18 February 2006 12:49 pm, Wilson Bilkovich 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
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 01:08 pm, petermichaux@yahoo.com 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
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 18/02/2006, at 3:29 PM, tsumeruby@tsumelabs.com wrote:
On Saturday 18 February 2006 01:08 pm, petermichaux@yahoo.com 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
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 Saturday 18 February 2006 02:21 pm, Scott Weeks wrote:
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, tsumeruby@tsumelabs.com <tsumeruby@tsumelabs.com> wrote:
guidelines, Dentrix is another great example for having a decent mouse based
interface to describe the teeth of a patient.
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
On 18/02/2006, at 5:05 PM, tsumeruby@tsumelabs.com wrote:
On Saturday 18 February 2006 02:21 pm, Scott Weeks 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! 
Tsume
On Sat, 2006-02-18 at 18:11 +0900, Gregory Brown wrote:
On 2/18/06, tsumeruby@tsumelabs.com <tsumeruby@tsumelabs.com> 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 DentrixIn fact... some of that is what Ruport is designed for. Reporting on
dentrix / dx1 crud.
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
On Sun, 2006-02-19 at 06:27 +0900, Scott Weeks wrote:
You haven't peeked at the database... have you?
On 2/18/06, Tsume <tsumeruby@tsumelabs.com> 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!
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.
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 2/18/06, Gregory Brown <gregory.t.brown@gmail.com> wrote:
On 2/18/06, Tsume <tsumeruby@tsumelabs.com> 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!
Well, no. Supposedly its huge. I probably shouldn't look.
Tsume
On Sat, 2006-02-18 at 23:23 +0900, Gregory Brown wrote:
On 2/18/06, Tsume <tsumeruby@tsumelabs.com> 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?
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 Sat, 2006-02-18 at 23:25 +0900, Gregory Brown wrote:
On 2/18/06, Gregory Brown <gregory.t.brown@gmail.com> wrote:
> On 2/18/06, Tsume <tsumeruby@tsumelabs.com> 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!
>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.
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 Gray II
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.
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 2/18/06, Tsume <tsumeruby@tsumelabs.com> wrote:
On Sat, 2006-02-18 at 23:25 +0900, Gregory Brown wrote:
> On 2/18/06, Gregory Brown <gregory.t.brown@gmail.com> wrote:
> > On 2/18/06, Tsume <tsumeruby@tsumelabs.com> 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!
> >
>
> 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.