Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

TK vs. Web pages

by apl (Monsignor)
on Apr 02, 2007 at 15:34 UTC ( #607851=perlmeditation: print w/ replies, xml ) Need Help??

I've bought a (used; 2002 edition) copy of Mastering Perl/TK, as it is out of print. This surprised me, as I'd have thought that if Tk was useful it would remain in print.

Philosophically, is Tk the proper way to develop a GUI for a Perl app? Are those of you more experienced than I using Web pages (as one example) to gather parameters and display results?

Thanks in advance for your thoughts on the matter.

Comment on TK vs. Web pages
Re: TK vs. Web pages
by perrin (Chancellor) on Apr 02, 2007 at 16:33 UTC
    The short answer is that web apps are the default GUI these days. They're quick to develop and easy to (not) distribute to users. It doesn't mean Tk doesn't have its uses, but most people will consider a web app first.
      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.
Re: TK vs. Web pages
by Fletch (Chancellor) on Apr 02, 2007 at 16:47 UTC

    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.
Re: TK vs. Web pages
by TGI (Vicar) on Apr 02, 2007 at 17:53 UTC

    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.


    TGI says moo

      Many thanks. You are a gentleman and a scholar.
Re: TK vs. Web pages
by zentara (Archbishop) on Apr 02, 2007 at 18:26 UTC
    It really depends on what you need to do with your app. If it's a heavy use site, you will have a hard time competing with apache and cgi(mod_perl) for performance reasons.

    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


    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
Re: TK vs. Web pages
by GrandFather (Cardinal) on Apr 02, 2007 at 21:57 UTC

    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?


    DWIM is Perl's answer to Gödel
      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...

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

        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
Re: TK vs. Web pages
by DrHyde (Prior) on Apr 03, 2007 at 09:22 UTC
    I gather that Wx is what the cool kids use these days. The interface (both for the programmer and the user) certainly looks a lot better than Tk's does.
      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.
Re: TK vs. Web pages
by mamawe (Sexton) on Apr 03, 2007 at 13:05 UTC
    I personally prefer web pages for their ease of use on different OS.

    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.

Re: TK vs. Web pages
by jdrago_999 (Hermit) on Apr 06, 2007 at 14:00 UTC
    While there are many people who do things the "old" way - by putting HTML inside your Perl code:
    #!/usr/bin/perl -w use CGI; my $q = CGI->new(); print $q->header(); print "<p>Hello, " . $q->param('name') . "!</p>\n";

    The trend for some time has been to use a templating engine such as Apache::ASP (my favorite) or Template::Toolkit. These allow you to place Perl inside your HTML.

    Example:
    <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>

    Depending on your needs (i.e. - Session management, mod_perl, etc) each option has its own strengths and weaknesses. Keep asking until you find what you're looking for.

    My only advice is to use the simplest thing that will get the job done.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://607851]
Approved by Corion
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (7)
As of 2014-12-26 03:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (164 votes), past polls