Forum: Ruby-Gnome 2 Console to GUI

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Will D. (Guest)
on 2008-10-03 20:49
Attachment: pc.rb (0 Bytes)
I apologize if the following question has an obvious answer. I've
developed a console application that works perfectly, but in console. I
come from basic VB coding, so I'm used to subprocedures: ->
go to this_sub. However, with GTK2 (as well as Ruby itself), it's
different. The way my console app works is rather simple: it's basically
one huge IF statement, connected to each and every cell value in an
Excel spreadsheet.

if cell1 == "Value1" and cell2 == "something else" then
puts "The output"
elsif cell1 == "Value2" and cell2 == "something else" then
puts "A different output"
puts "Value not found"

For every 'IF' situation I just have the 'puts' command after that,
which populates the output in console. The reason it's a huge IF
statement is because of my lack of knowledge on how to use Excel-based
database if values within my Ruby app. Technically (and practically)
speaking, my app is not talking to the Excel file at all - it's all
hard(hand?)-coded. I totally understand that my whole code is quiet
redundant to say the least.

For now, is it (and I think it certainly is) possible to replace/recode
the 'puts' method to something more relevant, for instance:

e =
if cell1 == "Value1" and cell2 == "something else" then
e.text "The output"
elsif cell1 == "Value2" and cell2 == "something else" then
e.text "A different output"
e.text "Value not found"

I've included the file that I have, but it doesn't have anything related
to Gtk, sorry about that. I'm a beginning Ruby programmer, and any
suggestions are welcome. And thank you for your time.
Mike C. (Guest)
on 2008-10-04 04:44
(Received via mailing list)
Hi Will.  I'm replying privately because probably the discussion doesn't
have much to do with GTK2.

It's great that you're getting into Ruby!  As you go along I think
you'll find that it's much more flexible than VB.  But as you noticed,
it may take some time to learn all the concepts and techniques that
will make you an efficient programmer.  Don't worry; just take it
slowly, one bit at a time.

I thought about guiding you through the refactoring to make this
program easier to read/write, but then decided against it.  Since you
are just starting out, I think it would be better for you to find your
own way.  But here are some suggestions to help you find the path.
I'm sorry that the discussion is so long... :-P

1. Start off trying to write subroutines.  Since you are probably used
writing small VB scripts, you may be thinking it is unnecessary.  But
as your desire to write more and more complicated programs develops,
this will help keep the program simple to manipulate.

Subroutines look like:

def my_subroutine(a, b, c)
    return a/b + c

Then you can call it just by typing:

my_subroutine(myA, myB, myC).

The last line of your script should call one of the subroutines.  When
first get started doing programming like this, you should get into the
of having your main script only be 1 line.  All of the other subroutines
should be about 5 lines long, and never more than 10.  1 line long
are really useful for improving readability.  For example:

def q1_2006?(date)
    return date.between?(Date.Parse("1/1/2006", "3/31/2006")

Then you can say

if q1_2006?(date)

When you first start out, it will be quite a brain teaser to keep trying
to keep
your subroutines so small.  You will probably be thinking that you are
more time doing that than writing the whole blasted thing.  But trust
When you keep the subroutines small, it keeps the problem solving
Opportunities to do what you want will spring out of nowhere.  One of
biggest problems you have with making your program fit with GTK is that
you've got a big blob of code and it's hard to massage it into the
shape you need.

One very important point is that if you return a value from your
subroutine it
should *always* be the last line of the subroutine.  Never return early.
When you get more advanced and understand where you can break this rule,
it doesn't always hold.  But when you are getting started, you need to
it religiously.

2. Don't use global variables -- ever.  OK.  I admit that on ocassion
global variable
are actually essential.  And if you know what those ocassions are,
then it's all good.
But when you're first starting out, you will never run into these
issues.  Trust me :-)
Don't ever use a global variable.

The problem with global variables is that it allows you to "cheat" a
little bit on the
design of your code.  It makes a few things easier up front (i.e., you
can get the
data you want without work).  But the downside is that it makes your
more difficult to manipulate later (pretty much same issue as the
So when you forbid the use of global variables, your code magically
easier to use (though harder to design up front).

How do you do it?

Basically you pass all the variables you need into the subroutine.
Yes, sometimes
that means you are passing a lot of variables around.  But if you keep
subroutines small, it won't happen so much.  The key here is that you
will start
hating to pass yet another variable around and you will start to think,
"How can
I do that differently".  This will result in code that is much more

3. OK, those are the basics.  You can also start to look at object
oriented design for
your code, but it takes a good 6 months of constant use to really
internalize the
ideas.  It's best to start just with good modular programming, which
is what I've

But once your code is modular, you can start to do more overall
structural design.
And this is where you will start to find it obvious how to integrate
with GTK.
Generally speaking, you code should be designed with 3 areas: input,
and output.  You should have subroutines that get input; subroutines
that process
the input into a final result; subroutines that output the final
results to the user.
Then you have an overall script that calls the input, processing and
output methods.
(Remember: subroutines have to be small!  So be careful here.  Don't
be afraid to
write a *lot* of small subroutines!!!)

Once you have this, you can start to see what to do:  You have your
data structures
which contain the GTK input widgets.  You pass it to your subroutine to
the input you want.  Now you process the information.  Then you pass the
to a subroutine along with the GTK output widget to output the data.

This is a modular way to do it.  Object oriented is a little
different.  You have an
object (called a "Controller") that contains the GTK widget.  It has
methods on it
to get the input.  You have another object (called a "Model") that
processes the
input.  You have a final object (called the "View") that contains the
GTK widget
with will display the result to the user.  This pattern is known as
"Model View Controller"
or MVC for obvious reasons :-).

4. My last piece of advice is to look at the example code that comes
ruby-gnome.  Most of this code is truly horrible and doesn't follow any
of the rules I stated above.  But look at it anyway and try to write a
"prototype" of the UI that you want.  Don't do any processing at all.
Just do the input and the output (with fixed data that you make up).
Then try to transform the code into small subroutines like I mentioned
before.  At that point, I think it will be obvious how to fit the
in there.

Sorry for the long rant :-).  You *did* ask for suggestions...  I've
been a programmer
for a couple of decades now and I started out exactly the way you did --
noodling around with some stuff I wanted to do.  Keep plugging away
and learn a little bit by little bit.  Keep practicing as much as you
Read other people's code.  And feel free to ignore my advice if it
doesn't work
for you :-)

Will D. (Guest)
on 2008-10-04 05:24
Mike C. wrote:
> Subroutines look like:
> def my_subroutine(a, b, c)
>     return a/b + c
> end
> Then you can call it just by typing:
> my_subroutine(myA, myB, myC).

Aha! I read this in the book. They called it methods.

> And feel free to ignore my advice if it doesn't work for you :-)

Come on now, you've spent so much time and energy on this post, I *will*
take your advice into account and start practicing! Lots of thanks!
Mike C. (Guest)
on 2008-10-04 06:22
(Received via mailing list)
On Sat, Oct 4, 2008 at 10:24 AM, Will Dexter
<removed_email_address@domain.invalid> wrote:
> Come on now, you've spent so much time and energy on this post, I *will*
> take your advice into account and start practicing! Lots of thanks!

Hi Will.  I'm glad you found the advice useful.  Feel free to email
me for any questions you might have.  I enjoy talking about programming,
so I'm happy to help if I can.

This topic is locked and can not be replied to.