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…
- 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:
return date.between?(Date.Parse(“1/1/2006”, “3/31/2006”)
Then you can say
When you first start out, it will be quite a brain teaser to keep trying
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
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
- Don’t use global variables – ever. OK. I admit that on ocassion
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.
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
hating to pass yet another variable around and you will start to think,
I do that differently”. This will result in code that is much more
- 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
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
And this is where you will start to find it obvious how to integrate
Generally speaking, you code should be designed with 3 areas: input,
and output. You should have subroutines that get input; subroutines
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
(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
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
input. You have a final object (called the “View”) that contains the
with will display the result to the user. This pattern is known as
“Model View Controller”
or MVC for obvious reasons :-).
- 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
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