Ruby seems pretty eash to code and understand. However, as a
non-professional programmer, I find GUI the hardest part so far.
GTK didn’t work out of the box on windows. It is too bad because it
looked like it would be one of the better GUI choices. I guess I will
have to try FOX.
Any suggestions?
Are there any good examples of getting tk widget data to ruby?
Here is a simple example where I try to build an interface for the user
to pick information which will then be sent to ruby to process.
#example:
require ‘tk’
cash_locs=[‘NONE’,‘NY1’,‘NY2’,‘NJ1’,‘ETC.’]
root = TkRoot.new() { title “PICK LOCATION” }
bar = TkScrollbar.new(root).pack(‘side’=>‘right’, ‘fill’=>‘y’)
fromLoc = TkVariable.new
list = TkListbox.new(root){}
list.pack(‘side’=>‘left’, ‘fill’=>‘both’, ‘expand’=>true)
list.yscrollbar(bar)
cash_locs.each { |loc|
list.insert(‘end’, loc)
}
button = TkButton.new(root) {
text ‘OK’
command proc {fromLoc.value=list.curselection(),TkRoot.new.destroy}
}
button.pack()
TkButton.new(nil, ‘text’=>‘Quit’,
‘command’=>proc{TkRoot.new.destroy}).pack(‘fill’=>‘x’)
Tk.mainloop()
puts 'USER PICKED: '+cash_locs[fromLoc.value.to_i]
These days most people use the web for their GUI’s. Have you considered
this? It doesn’t have to be a web app per se. Ruby has lots of good
options in this area.
On 4/4/06, greg.rb [email protected] wrote:
Ruby seems pretty eash to code and understand. However, as a
non-professional programmer, I find GUI the hardest part so far.
Generally, gui is the hard part of software that has to communicate
with the user. It takes a lot of work to get at least some gui with
the most importatnt options somewhere, and even more difficult to make
one that is easy to use.
Some people find gui builders helpful. They allow you to design
dialogs, menus, etc, and just load them ito your application. iirc
qtruby supports such thing.
Creating dialogs on the fly is more versatile. You can add different
controls when your application is in different states. But then you
should look for toolkit with ruby bindings that makes constructing the
layout easy.
For example, the tk toolkit only provides very primitive ways of
arranging elements. I am not sure if the ruby library provides some
more complex layouts. But with tk alone it may be quite hard to
create a dialog with different kinds of elements that won’t make the
users run away 
Thanks
Michal
From: “greg.rb” [email protected]
Subject: is GUI a weak point?
Date: Wed, 5 Apr 2006 05:23:59 +0900
Message-ID: [email protected]
Are there any good examples of getting tk widget data to ruby?
Here is a simple example where I try to build an interface for the user
to pick information which will then be sent to ruby to process.
I couldn’t understand what you want to ask.
Although the following is one of the samples rewriting yours,
it may not be able to answer your question.
require ‘tk’
cash_locs=[‘NONE’,‘NY1’,‘NY2’,‘NJ1’,‘ETC.’]
#--------------------------------
callback function
def put_picked_value(s)
puts 'USER PICKED: ’ + s
end
#--------------------------------
GUI part
Tk.root.title ‘PICK LOCATION’
TkButton.new(:text=>‘Quit’,
:command=>proc{exit}).pack(:side=>:bottom, :fill=>:x)
f = TkFrame.new.pack(:fill=>:both, :expand=>true)
list = TkListbox.new(f)
list.yscrollbar(TkScrollbar.new(f).pack(:side=>:right, :fill=>:y))
list.pack(:side=>:left, :fill=>:both, :expand=>true)
list.insert(:end, *cash_locs)
list.bind(‘ButtonPress-1’,
proc{|y| put_picked_value(list.get(list.nearest(y))) },
‘%y’)
Tk.mainloop()
I am thinking about this problem at the moment. There are a lot of
toolkits for ruby, but they all require different libraries and are a
bit painful to get running. I am writing software for both OSX and
linux.
I have played with the following toolkits but I haven’t made any
decisions:
There are plenty of others but one thing that I would like to see/like
to start is a wrapper that allows you to switch between all of the
given frameworks using some sort of configuration.
I think it would be good to describe the interface for a button,
window, pane etc and then put wrapper classes around all of the
toolkit implementation classes.
I’m not sure how much interest this would generate in the community
but I would be interested to find out.
Cheers,
Carl.
There are plenty of others but one thing that I would like to see/like
to start is a wrapper that allows you to switch between all of the
given frameworks using some sort of configuration.
Seems like a lot of effort for very little return. As somebody else has
already said, if you want a cross-platform GUI, you’re probably going to
want to be using Rails.
There really isn’t such thing as a cross-platform GUI application,
outside of web-land. It always needs tweaking, refining, polishing and
testing for every major platform; as a result, what you’re suggesting
offers very little.
Martin
Java offers cross platform gui development that doesn’t require
tweaking. Rails is great but webapps aren’t everything. When you are
trying to develop 3d applications or applications that just need to be
run on a desktop (there are still plenty) then ruby is lacking.
On Apr 5, 2006, at 6:29 AM, [email protected] wrote:
want to be using Rails.
Using Rails and a web interface is a nice way to present data to an
end user, but it’s not always a viable solution. For example, my
company does diesel engine testing in real time. There’s no way a
web based Rails interface would even come close to being able to meet
our needs for that.
Now, to present the generated data to the end user - Rails works
beautifully. But the web is not the end all be all for GUI
applications.
There really isn’t such thing as a cross-platform GUI application,
outside of web-land. It always needs tweaking, refining, polishing and
testing for every major platform; as a result, what you’re suggesting
offers very little.
I would argue the same is true in webland, since most people designer
end up having to support IE, Firefox, Safari, and more.
On Wed, Apr 05, 2006 at 07:37:27PM +0900, Carl W. wrote:
Java offers cross platform gui development that doesn’t require
tweaking.
Believe me, it doesn’t. I’ve spent a significant proportion of my
professional career pushing against this prevalent misfact.
Friends don’t let friends Swing.
SWT, despite IBM’s claims to the contrary, needs separate builds for
each platform, similar but not the same UI code, and a significant
amount of work to get the UI to look and feel “right” on Windows, Linux
and Mac OS X, and fit in fully with its UI conventions and way of
working.
Even then, SWT is DOG SLOW on Linux, almost to the point of uselessness.
See: Eclipse.
Ruby’s nearest equivalent to SWT is wxRuby, which you’ve already tried.
There is no such thing as a cross-platform UI. Even with wxRuby, you’ll
need to do a lot of work to get the UI to a point where Mac users,
Windows users and Linux users will all hate it equally.
Martin
I would argue the same is true in webland, since most people designer
end up having to support IE, Firefox, Safari, and more.
True. But increasingly, the lovely, lovely people behind Rails and Dojo
are doing the hard work so we don’t have to.
Martin
On 4/5/06, Michal S. [email protected] wrote:
On 4/4/06, greg.rb [email protected] wrote:
For example, the tk toolkit only provides very primitive ways of
arranging elements. I am not sure if the ruby library provides some
more complex layouts. But with tk alone it may be quite hard to
create a dialog with different kinds of elements that won’t make the
users run away
Layout options in Tk and most GUI toolkits are much less primitive
than HTML layout.
On Wed, Apr 05, 2006 at 08:57:30PM +0900, Mark V. wrote:
than HTML layout.
HTML has no layout out at all.
And Lo, the lord spake, and he gaveth of the world CSS, and saw that it
was good.
Of course, that’s an issue for graphic designers. We’re programmers. Let
people with some taste do the CSS and laying out.
Martin
John wrote:
I haven’t tried Gtk or wxRuby, but FxRuby (based on FOX GUI) is quite
good. I find it to be easier to use than Ruby/Tk - for example, in
FxRuby, scrollbars come for free, there’s a TreeList that’s as easy to
use as any other language’s tree view, and keyboard shortcuts (in a list
box, press ‘b’ and the selection should jump to the first item beginning
with ‘b’, that kind of thing) and mouse scroll wheels tend to work for
free.
One issue with Ruby is that there’s no full all-singing-all-dancing IDE
which will do a lot of the hard work for you. For example, C# guys
(including me when I’m not writing installations or programming Ruby)
get VS.NET or #Develop, both of which have form designers. Since the
form designer works out all the positioning, it makes it easier for the
programmer.
However, since languages like Ruby don’t have a full IDE (yet), you have
to do more manually. To alleviate this, languages such as Ruby tend to
use GUI libraries that make this as simple as possible. However, this
does not result in GUIs that look particularly nice, and .
and can be harder to implement.
Sorry about that!
On Wed, Apr 05, 2006 at 10:28:48PM +0900, John wrote:
I haven’t tried Gtk or wxRuby, but FxRuby (based on FOX GUI) is quite
Mac support only with X11. Gah.
Only use if you want Mac users to hate you. Really hate you.
Martin
I haven’t tried Gtk or wxRuby, but FxRuby (based on FOX GUI) is quite
good. I find it to be easier to use than Ruby/Tk - for example, in
FxRuby, scrollbars come for free, there’s a TreeList that’s as easy to
use as any other language’s tree view, and keyboard shortcuts (in a list
box, press ‘b’ and the selection should jump to the first item beginning
with ‘b’, that kind of thing) and mouse scroll wheels tend to work for
free.
One issue with Ruby is that there’s no full all-singing-all-dancing IDE
which will do a lot of the hard work for you. For example, C# guys
(including me when I’m not writing installations or programming Ruby)
get VS.NET or #Develop, both of which have form designers. Since the
form designer works out all the positioning, it makes it easier for the
programmer.
However, since languages like Ruby don’t have a full IDE (yet), you have
to do more manually. To alleviate this, languages such as Ruby tend to
use GUI libraries that make this as simple as possible. However, this
does not result in GUIs that look particularly nice, and .
Caleb T. wrote:
want to be using Rails.
Using Rails and a web interface is a nice way to present data to an end
user, but it’s not always a viable solution. For example, my company
does diesel engine testing in real time. There’s no way a web based
Rails interface would even come close to being able to meet our needs
for that.
Until they give the browser persistent connections to the server =)
Zach
Using Rails and a web interface is a nice way to present data to an end
user, but it’s not always a viable solution. For example, my company
does diesel engine testing in real time. There’s no way a web based
Rails interface would even come close to being able to meet our needs
for that.
Until they give the browser persistent connections to the server =)
Look at what GMail has been able to do with XMLHttpRequest.
If I were you, I’d check out Rails 1.1’s RJS support, Dojo, etc., and
check out some of the suprisingly fab stuff you can do with Async
Javascript.
Martin
[email protected] wrote:
If I were you, I’d check out Rails 1.1’s RJS support, Dojo, etc., and
check out some of the suprisingly fab stuff you can do with Async
Javascript.
What I’m getting at is that there is time involved with the setup,
handshake, connection and termination of each XmlHttpRequest. A
persistent connection only incurs each of those once.
To get good performance for lots of data it would be awesome to open a
connection and then to have it open for the remainder of the site visit.
=(
Zach
Cross platform GUIs is a very serious problem today and one without
clear solution. I agree with everyone pushing the web interface but
it does have it’s limitations. Here’s my suggestions (if a web
interface doesn’t work):
-
Give up. If you want a high quality GUI on multiple platforms give
up trying a single solution and realize that you will need to
implement the GUI in a native toolkit on each platform. Yes, this is
a tremendous amount of work but, if you want high quality, it is the
only viable solution. The difficulties can be partially ameliorated
by proper abstraction and separation of GUI vs. non-GUI.
-
If it’s simple, use Tk. Tk has major limitations and is totally
unsuited for complicated modern interfaces. That being said, it is
excellent for simple interfaces and is the closest thing to a cross
platform toolkit we have. I’ve been using Tk with various languages
for over a decade now and have managed to build some rather
complicated GUIs/programs with it. For simple GUIs and rapid
prototyping it has been a joy; for serious GUI work, a nightmare.
-
Pick whichever of the alternatives (see the rest of the thread) you
think will suceed in the future and hope you’re right. There is a
definite need for a crossplatform GUI toolkit; Tk is no longer
fulfilling that need, Java never did, and the other contenders are
only satisfactory on a subset of platforms. Sooner or later one of
these contenders or a new one will provide good functionality on all
platforms. My guess is Fox but I’m not taking bets.
c.
On Wednesday 05 April 2006 09:40 am, [email protected] wrote:
Using Rails and a web interface is a nice way to present data to an end
user, but it’s not always a viable solution. For example, my company
does diesel engine testing in real time. There’s no way a web based
Rails interface would even come close to being able to meet our needs
for that.
Until they give the browser persistent connections to the server =)
Look at what GMail has been able to do with XMLHttpRequest.
I can easily imagine that the output the first poster (above) refers to
(the
results of diesel engine testing in real time), are oscilloscope type
stuff,
which generally would be difficult to reproduce (in real time) on a web
interface. But, I suspect the frequency range required is not in the
MHz or
GHZ range, but instead in the KHz range?
In any event, at some point the web interface would find it difficult to
keep
up–say you’re testing ICs (integrated circuits, just to avoid confusing
with
Internal Combustion engines) in real time. But, at some point maybe you
resort to snapshots of the data, digital sampling / recording of the
data
(like sampling of audio or video streams), Fourier transforms (??), or
some
other (more) clever approach.
(sorry about losing the attributions, they were not in the post I’m
responding
to)
Randy K.