Home > Archive > PerlTk > May 2005 > New Perl Tk Tutorial
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
New Perl Tk Tutorial
|
|
| Binny V A 2005-05-02, 3:58 pm |
| Hello Everybody,
I have written a tutorial for the Tcl/Tk language
and have decided to translate the Tk part of the
tutorial to perl. So now I have a Perl/Tk tutorial.
It is available at
http://www.geocities.com/binnyva/co...rl_tk_tutorial/
If any of you could spare the time, please have a look
at my tutorial and let me know if you find any errors/omissions.
Thank you for your time.
Binny V A
http://www.geocities.com/binnyva
| |
| Ala Qumsieh 2005-05-02, 3:58 pm |
| Binny V A wrote:
> Hello Everybody,
>
> I have written a tutorial for the Tcl/Tk language
> and have decided to translate the Tk part of the
> tutorial to perl. So now I have a Perl/Tk tutorial.
> It is available at
> http://www.geocities.com/binnyva/co...rl_tk_tutorial/
>
> If any of you could spare the time, please have a look
> at my tutorial and let me know if you find any errors/omissions.
>
> Thank you for your time.
I went into this hoping for the worst, having read your earlier Perl
tutorials. Let's see.
To nitpick:
- "Tk, the extension(or module) that makes GUI programming in perl possible"
This implies that Tk is the only GUI module for Perl, which is not the case.
- "[Comments are] used by programmer to talk to themselves."
Correct, but they are also used to talk to other programmers who might
be editing your code later on.
- "It is good practice to make as much comments as possible."
Not necessarily. Comments are good as long as they convey the intention
of the programmer. There are bad comments that don't add much
information, and that can cause more confusion. Comments also need to be
updated with the code. There is nothing worse than outdated comments.
For example, your comment:
# Main Window
my $mw = new MainWindow;
is completely useless, and does not add any new information. I would
drop it since it is just line noise.
- "Please note that operator used here is '=>' as opposed to the one
used earlier '->' in $mw ->."
I think the above sentence is weak. You don't explain what => and ->
mean and do. Treating the reader of your tutorials like an idiot will
not advance them much.
- "The widget variable of all widgets must be unique and will be used
whenever that widget needs to be accessed."
This implies that the "widget variable" is something special to PerlTk.
It is just a simple Perl scalar. And, you don't need to save the
reference of each and every widget in a variable. Save only the ones
that you'll need to access later.
- "You may have noticed that I used a slash(\) in the command callback
(-command =>\&push_button);). Make sure that the slash stays there - to
see why, go to the Most common mistakes by Perl/Tk beginners."
Again, you don't explain what the backslash is, what it does and why is
it necessary. There are "programmers" who don't mind mindless
copy/paste, but you should explain why things are the way they are for
the rest.
- "[A Text widget is] similar to the entry widget but a larger version
of it."
True, but not completely. A Text widget is much more powerful than the
simple Entry.
- "The canvas widget is a very impotent widget"
Impotent? ;)
- "[Pack] is for you lazybones out there. Just put $widget -> pack; and
the widget will be packed."
The Packer is much more powerful and complicated than you explain it to
be. Of course, it is sufficiently explained in the Tk::pack docs.
Overall, I would say the tutorial is not as bad as I expected (going in
with very low expectations), but it's not that good either. The examples
are for the most part very contrived and confusing. You switch back and
forth between different constructs unnecessarily. Once you are using
pack, then grid, then pack again, and you have not yet explained what
pack and grid are. It's better to try and build a small application, and
explain its elements as you go. There is not much explanation happening
other than "just do it because this is the way it is" sort of behaviour,
which leads me to conclude that you yourself do not understand exactly
why things work the way they do. In some cases, you over-explain, like
explaining what a Button is, or a Scrollbar or a Menu. Since your target
audience are programmers, you can expect them to have used a computer
before.
--Ala
| |
| Rob Seegel 2005-05-03, 3:58 pm |
| Binny V A wrote:
> Hello Everybody,
>
> I have written a tutorial for the Tcl/Tk language
> and have decided to translate the Tk part of the
> tutorial to perl. So now I have a Perl/Tk tutorial.
> It is available at
> http://www.geocities.com/binnyva/co...rl_tk_tutorial/
>
> If any of you could spare the time, please have a look
> at my tutorial and let me know if you find any errors/omissions.
>
Some thoughts:
Early on you establish that the intend to teach Perl/Tk and not Perl
-- a few times in fact. The following is from the Starting page, however
there are other similiar sounding passages elsewhere in the tutorial.
<snipped from tutorial>
"Two more things before we begin the tutorial. I will be teaching
perl/tk and I expect you to know how to program in perl. I may ignore
some of the perl coding conventions like including use strict;, -w or
use warnings; in my examples. The examples have only one purpose - to
demonstrate the feature that will be taught in that part of the
tutorial. Sorry about that - but I have to keep my tutorial's example
scripts short and to the point.
Finally, this is a tutorial for Perl/Tk only - I will not be teaching
perl here. So if you know perl, continue. But if you are a beginner to
perl, I would recommend that you read my perl tutorial.
</snipped from tutorial>
Suggestions:
With a longish tutorial such as this, I think it's a good idea to
provide a summary that sets expectations for the reader. Some of the
things as a reader I would like to know:
PREQUISITE KNOWLEDGE/SKILLS:
- What level of knowledge is assumed? What sorts of skills in Perl are
useful to know or be aware of before starting the tutorial? You may also
provide links to other tutorials - perhaps to one or more at
http://perldoc.perl.org. The Perl tutorial you link to is titled "CGI
Perl" and "Beginner's Tutorial for CGI Perl Language." There is no
language called CGI Perl.
Within the short extract I snipped you state twice that those reading
the tutorial should already know how to program in Perl, yet several
times throughout the tutorial you spend time going over basic Perl
skills. Some of these basic points are even covered within the "CGI
Perl" tutorial referenced early on - so why cover them again?
INTENDED AUDIENCE/PURPOSE
Why should I read this? There are other tutorials and books out there
that cover Perl/Tk. What do you deliver within this tutorial that a
reader cannot get elsewhere? To be clear, its not a sin to be providing
information that is available elsewhere. You may have a different slant,
or you may present the information in a new and novel way. If so, there
is always room for other perspectives. A few examples:
-- A primer that takes a "learn by example" approach that features
several concise, but complete examples and screenshots that illustrate
basic toolkit use and functionality.
-- A guide to API changes from the Tk800 release and the Tk804 release,
that features new widgets and options, and changes that may have an
impact on existing code.
-- An article to current Windows/Unix incompatibilities and notes on
considerations that developers should take into account when developing
a truly cross-platform application.
A few lines could sum up what you intend to cover, and can help your
tutorial find its intended audience. Even if I've a more advanced
developer, and your tutorial covers basics, that's useful information,
because I may then pass it to others who are starting out even if I
don't use it myself.
ATTENTION TO DETAIL/CONSISTENCY
It's amazing how seemingly small details can have a cumulative effect on
the quality of a document. Depending on the publiction, a few minor
slips might be forgiven, but numerous inconsistancies and errors stand
out and draw unwanted attention to how you provide information rather
than what you provide. Worse, it may lead readers to question your
credibility as a source of knowledge.
Minor nitpicks in the extracted Text:
- How many times do you write "perl" when it should be Perl?
- You write Perl/Tk in some places and perl/tk in others.
- You could probably combine the paragraphs with little effort so that
you avoid repeating yourself needlessly.
- You probably ought to run text through a spell-checker.
- You draw some attention to the fact that you won't be using "use
strict" within your scripts, and I can __somewhat__ understand the
reasoning. If the tutorial were a primer-level, I might include it to
reinforce the "best practice." I might choose to leave it out if the
tutorial assumed more knowledge, the same way I might leave out
#!/usr/local/bin/perl from each small example. If you do decide to leave
it out, regardless of the reason, and you provide an example that
contains bugs that "use strict" would have identified, then you take a
risk at looking foolish. Besides, how much space are you really saving
by omitting it? You could always throw it back in there and remove the
not-so-useful "# Main Window" comment. Moving on...
TABLE of CONTENTS
I will rarely buy a book that has a lousy Index and/or Table of
Contents. Instead of "Widgets 1,2,3..." perhaps you could have used the
word Chapter or Lesson. You might put some more text in the TOC to make
it a bit more descriptive. A few words that describe a Lesson, or
individual widgets might not be a bad way to go.
I briefly browsed through several pages, a few things stood out to me.
- Unnecessary Remarks:
You ought to seriously consider dropping the following excerpt and watch
out for other areas where you state similar things:
"Now Perl puritans will raise a great hue and cry and say that this is
not the way to print "Hello World". The "pure" method is the
following..."
#!/usr/local/bin/perl
print "Hello World"
"Putting things in perspective, I am teaching Perl/Tk - not Perl. The
above is the Perl method of doing it. My method is the pTk method of
doing it."
These three paragraphs contribute nothing to your overall tutorial. What
value did you think they provided? I suppose it could be chalked up to
writing style, but it strikes me as a waste of space and vaguely
inappropriate -- my opinion.
- Logical Progression of Lessons
The way you have ordered your lessons isn't too bad, but I think I might
have done it a little differently. Was there a logical ordering to your
lessons? Both Canvas and Text deserve their own lessons, IMO.
- Awkward Table use
HTML Tables can be a really good way of formatting tabular information,
but I found some of your tables difficult to read when the text was all
bunched up. I think the effect was all the worse because the central
white space that the tutorial was put into was sandwiched between two
columns.
This is just a few things that jumped out at me. Sorry if the feedback
isn't that positive. It looks like you spent some time on it and put
some effort into it, but it reads like a rough cut that could use some
polishing.
Rob
| |
| binnyva@hotmail.com 2005-05-03, 3:58 pm |
| Thanks for the feedback. I have corrected most of the mistakes.
> Overall, I would say the tutorial is not as bad as I expected
> (going in with very low expectations), but it's not that
> good either.
When you look at the other Perl Tk tutorials on the web, my
tutorial won't looks so bad. There are some very good tutorials
on Perl, and some very good ones on Tcl/Tk but very few tutorials
on Perl/Tk. And the few tutorials on Perl/Tk, IMHO, are not
that good. I was hoping to remedy this situation with this tutorial.
So any help in making it a better one is greatly appreciated.
Once again thanks for the feedback - and keep them coming.
Binny V A
http://www.geocities.com/binnyva
| |
| Ala Qumsieh 2005-05-03, 3:58 pm |
| binnyva@hotmail.com wrote:
> Thanks for the feedback. I have corrected most of the mistakes.
Thanks. But why 'most' and not all?
> When you look at the other Perl Tk tutorials on the web, my
> tutorial won't looks so bad. There are some very good tutorials
> on Perl, and some very good ones on Tcl/Tk but very few tutorials
> on Perl/Tk.
A google search gives me a decent number of tutorials. Definitely not as
many as those on Perl or Tcl, but a good number nevertheless.
> And the few tutorials on Perl/Tk, IMHO, are not
> that good. I was hoping to remedy this situation with this tutorial.
I disagree with that statement. I actually find that most of the Perl/Tk
tutorials online are very good. The problem is that there aren't enough.
Plus, 'Mastering Perl/Tk' contains so much excellent information that it
has filled 99.9% of the void that existed a few years ago.
If you think there are bad tutorials out there, let us know what they
are, and we can go over them, and send feedback to their authors.
--Ala
| |
| binnyva@hotmail.com 2005-05-04, 8:56 am |
| Dear Rob Seegel,
Thanks for the feedback. You have provided so much suggestions
that it will take some time to implement them. I am working on
them, and will let you know as soon as the work is over.
> You could always throw it[use strict;] back in there and remove the
> not-so-useful
Yes, maybe I should include it. I think I will add them in all the
programs except the hello world program. It would take some time
and will let you know after the work is done).
> I found some of your tables difficult to read when the text was all
> bunched up.
I noticed that problem too. But I don't have a solution for it. I could
delete a column, but all three(Syntax, Description and Example) seems
equally necessary to me. The other option is to use a vertical layout -
but when I must explain multiple commands, it becomes a problem. Any
suggestions on how to make it better?
Thank You,
Binny V A
http://www.geocities.com/binnyva/code
|
|
|
|
|