To expand on the point(s) above:

• with a web interface you get a client/server architecture out of the box
• a large (if not complete) portion of your user base is going to have the client portion installed already
• conceptually a web / CGI model (here's a request, do something with this stuff, send me back a response) may be easier for many to get their head around, as opposed to event driven GUI programming which requires a different mindset
• coincidentally since many current "programmers" are familiar with the CGI model, it looks like the appropriate hammer for whatever nails they see
• pure supposition on my part here: non-technical people may be more inclined to pick up on using a web interface ("Oh, it's just another browser form") versus learning to use yet another custom application ("Where's the menu item to turn off that annoying paperclip; I hate those things. What do you mean it doesn't have a talking paperclip? All my other applications annoy me with one. This program is terrible! I mean come on, where's the paperclip?")

Update: More thought(s).

• Web interfaces are amenable to separating the application from its interface; 4 months down the road when the marketing department decides to rebrand and your app should now use the colors puce and taupe everywhere to match the corporate identity it's much easier to let J Random Designer update his CSS and not involve any real developers or have to make changes in code (granted with Tk you can do it to some degree with resource defaults, but not to the extent that you can completely rearrange a web page with CSS and/or structural changes to HTML templates that are orthogonal to the back end application logic)
• Related to the client/server remark above, with attention paid to standards and the browsers that ignore them (*cough*IE*cough*) you can get a very wide array of client OSen upon which your app is usable from

Many thanks.I shall sacrifice a turtledove in your honor.

I agree with Fletch 100%++

Web apps are great, I've used them to solve a number of probems. Stand alone gui apps are also very useful. It really depends on the sort of problems you are trying to solve.

If your app is designed to operate on one person's data on one computer, a web app adds a siginificant overhead that isn't necessary. "To run my calculator program, you must first install apache..."

If your app is designed to be run by many people simultaneously accessing shared resources, a web app is very probably the best way to go.

Of course, web apps do still suffer from relatively limited UI options. Not that pTk is an ultra modern GUI library or anything, but some types of interaction are easier to set up properly using a traditional application. The big question is whether the network client code you have to write is worth the tradeoff you make when you eschew the browser as a platform.

If you decide to go the GUI app route, there are a number of options for GUI libraries. You can read some discussion of GUI library choice at "Tk alternative?" and at "Some pre-project questions". SuperSearch should turn up abundant discussion on the issue of GUI library choice.

Many thanks. You are a gentleman and a scholar.

First, let me explain that I'm a dinosaur (migrating to Unix/Perl from PL/1 on a piece of Big Iron). So if I could, I'd like to ask one more (set of) questions.

Do you hand-code HTML, or is there a Perl lib that facilitates the construction of a page, or ...

To put it shortly, I understand how to construct the form if I was to use the Tk pm, but I'm not so keen on how to go about it using a Web page.

I appreciate your giving me your time.

There have been a few attempts to build GUI toolkits on top of HTML. Probably the most successful one in perl is bOP. None of them are widely used though. The common approach is to have design/HTML people who write HTML either by hand or with a tool like DreamWeaver and then integrate it into your application with something like Template Toolkit.

A lot of people seem to have latched onto the "web pages" phrase in your post, but it's not clear to me that you are developing a "distributed" application in a client/server environment. If that is indeed what you are after then a web application is pretty clearly the way to do it. But if you are developing a single user local application then Tk (or one of the other similar GUI tools for Perl) is much more obviously what you want.

It seems to me that the question is not GUI or Web, but more Client/Server or Single user - after that has been answered GUI or Web is much more obvious isn't it?

Thanks for noticing that. At this point, I'm more concerned with providing a test tool for use by a single QA person.

Currently I use Getopt to allow my user to specify what he needs. Since the tool doesn't get used with great frequency, he always has to specify the help option before he can specify what he needs.

I'd much rather be able to display a set of radio buttons and some scroll boxes so he can see his choices from the outset.

My research turned up references to Tk. Then I started wondering why the standard reference was out of print...

In that case Tk is a pretty clear choice. It is light weight for a job such as you describe and the somewhat non-native look doesn't matter at all. Actually you'd probably find you have it knocked out in crude form in an hour if you let pack manage the layout for you.

The Tk documentation is ok, but tends to be a bit scattered with some bits in non-obvious places. Important bits to be familiar with are Tk::options, Tk::pack, Tk::Radiobutton, Tk::Text and Tk::Label.

If you would like a light weight starting point take a look at Utility to capture parameters and perform a task or Tk Tutorial, Featuring Your Very Own "Perl Sig/OBFU Decoder Ring" for a tutorial that explores a little more of the functionality.

---

DWIM is Perl's answer to Gödel

Since apparently the user is already using a commandline interface, perhaps you should consider a console-based UI approach, e.g. curses?

But if it is a custom low use app, a Perl Tk or Gtk2 gui can be quite useful. It can run without a constant server going. It can use many different ports. It can use better encryption than the 128-bit web stuff. etc. etc.

If you go the roll-your-own route, the big problem is setting a protocol for you to use, and serializing data (so you can send hashes over the net).

The Net::EasyTCP makes this pretty easy. I have a demo at ztk-enchat encrypted server client

With regard to the gathering of parameters and display of results: most of the time I develop my applications as a library that can be used by CGI-Script and by CLI application.

That way I develop the functionality of the application with the command line client to speed up the development cycle.
Thereafter I write the CGI interface that just validates the input and calls the library functions.

As a side-effect I get a scriptable program to setup the application.

Try finding help for Wx, and compare it to support for Tk or Gtk2, I would say Gtk2 is the next step, although Wx is optionally a front end for Gtk2 or basic X libraries(which ever you choose). IIRC

---

I'm not really a human, but I play one on earth. Cogito ergo sum a bum

Thanks. I'll search and Google on Wx to see what it looks like.

#!/usr/bin/perl -w

use CGI;
my $q = CGI->new();
print $q->header();
print "<p>Hello, " . $q->param('name') . "!</p>\n";
[download]

<html>
<head>
  <title>Apache::ASP Example</title>
</head>
<body>
  <p>Hello, <%= $Request->QueryString("name") %>!</p>
<%
  for( 1...7 ) {
%>
  <font size="<%= $_ %>">The time is <%= scalar(localtime()) %></font>
  <br>
<%
  }# end for()
%>
</body>
</html>
[download]