Before going too far down the path of continuing to use Perl::Tk I would read Perl TK and the relevant responses.

I'm responding because I got excited about using Perl::Tk once and started writing things similar to your problem until I realized that the client needed Perl and to have Tk installed on their machines. My tests revealed that, in certain cases, Perl::Tk will not install properly:

sudo cpan -i Tk
...
Using -L/usr/lib to find /usr/lib/libX11.so.6.2.0
Cannot find X include files via /usr/include
Cannot find X include files anywhere.
You probably need to install the X11 development package first.
...
Running make test
  Make had some problems, won't test
Running make install
  Make had some problems, won't install
[download]

Once I was done answering the question, 'how often do I want to fight fires like this?' I opted for a different approach. For me, I abandoned trying to deploy rich GUI stuff and moved on to writing rich Internet applications instead. Nowadays what you can do with JavaScript has gotten so close to what could once only be done via a GUI that, in most instances, writing things to be installed on a desktop is just not worth the aggravation.

Remember that applications can all suffer from the 'popularity' problem. If what you wrote gets popular -- even in a corporate environment -- your installed base increases and so does the amount of effort it takes to maintain the application across versions. With a web application you can deploy new versions in a snap. With GUIs now you have to figure out how to update everyone's machine.

Another route you might want to consider, provided you have a small number of users, might be to use VNC as discussed here http://www.techotopia.com/index.php/Remote_Access_to_the_Ubuntu_Linux_Desktop#Accessing_a_Remote_Ubuntu_Linux_Desktop_from_a_Windows_System. This will not stave off the popularity problem but can work in a pinch.

So the next best thing, for over-the-internet-usage would be to run it via ssh. SSH has an option on the server to export the X session to the remote client. This works very well but has many drawbacks, such as
(1) your server must run with an X server going, which is not considered safe for large servers
(2)you have to allow your clients to have ssh access. If there are too many, it will bog things down, plus it's not easy for clients to setup.
(3)it's not browser based

Other than that, you will probably need to use javascript, css, and cgi to put together a similar page which a browser can use.

If it is just a handful of trusted clients, and you have control over your server so as to run an X-server, ssh is not a bad option. It would be similar to the VNC as mentioned by InfiniteSilence above.

It would be great if someone can develop a chopped down version of Perl, suitable to work as a browser plugin, much like the Java plugin.

It's been over a decade that I really worked with Tk, but here some meditation on the subject.

I'll address it to you since I know that you are quite an expert on this subject.

so IMHO

1. Tk heavily relies on callbacks.

2. The aim of those callbacks is located somewhere between 2 extremes^₄
   • a) manipulating the GUI (e.g reordering elements)
   • b) interacting with the application. (e.g. access DB)

3. Since Perl doesn't run within browsers, there are 2 options for those callbacks
   • A) porting to JS
   • B) tunneling callbacks via http to the server¹

4. For different reasons one would mainly like to go
   • a -> A # performance
   • b -> B # complexity, server bound

5. While it certainly is possible to mimic most (or all) Tk-widgets in HTML&JS, it's pretty unlikely to have an AI which analyzes the code to split it into a) and b) parts.

6. The most likely solution is to design a meta-language (maybe even a DSL) which is already addressing these needs.

7. This meta approach would create the necessary output in either Perl/Tk or Perl+JS/HTML²

8. having a restricted sub-dialect (intersection) which reliably translates Perl <-> JS shouldn't be impossible.³

What ya think, did I miss something?

footnotes

¹) with different possible approaches for client-server communication:

• classic http
• AJAX
• Web-Sockets (bidirectional)

²) or even other targets like Perl/Tkx or Perl/Wx or even Lisp/Emacs or whatever

³) But this restricted "Perl" could look very strange, e.g. only allowing scalars and hence only array-refs and hash-refs like

$array->push($a,$b)   <->   array.push(a,b)

... or only allowing function scopes and no block scopes (JS does hoisting of lexicals)

Cheers Rolf

( addicted to the Perl Programming Language)

updates

moved side-notes to footnotes.

more footnotes

^₄) somehow analogous to the MVC paradigm, making a distinction between template code (View) and pure Perl code (Controller).

You're hired! When can you start? :-)

Seriously, I think that Tk is out of the running for browser based displays, for all the reasons you mentioned.

I think that gtk3 may be the way. Why? Because firefox and many other open source browsers are currently gtk2/gtk3 based. That means that under the hood, they both would utilize the same signals and callback system.

It looks like Python is moving forward with pyXPCOM and similar interfaces, and IIRC there is a configure option in the newer mozilla browsers to enable experimental Python support.

It seems to me that Perl needs to get involved with XPCOM. It currently has C, C++, Python and Ruby. Where's Perl?

Of course, I find the whole desire to run everything in a web browser rather disgusting, resulting in code bloat and html/javascript which is as hard to read as assembly language.

In my little world, I would rather write custom scripts for clients to connect, vis ssh, keeping the browser and http servers out of it all together. :-)

---

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

Thank you for that.
I am struggling a bit since although I have been using Perl for over ten years and general programming for decades before that I simply have not anywhere near the Internet programming world.
I think you have said that Java can mimic the most Tk widgets so would be one thing to look at.
With Java would you be able to mimic the behaviour of altering say the contents of a pull down menu because a specific radio has been used.
What do you mean by 'meta language' and a 'DSL'?

> It would be great if someone can develop a chopped down version of Perl, ...

Something like perlito ? :)

Cheers Rolf

( addicted to the Perl Programming Language)

Pretty cool. I know recently, I saw the gtk3 c-libs had a javascript translation, and that might combine with Perlito to allow us to open windows in a browser. Better yet, would be to get Perl incorporated into something like the Silverlight-Python project to actually embed Python into Firefox. See PyGtk in a web Browser

---

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

One user has asked if this can be developed so that the GUI can be used over the Internet

What does that mean exactly?

The current system is implemented (has been working for several years) on a PC and allows the
user to enter product data using the usual GUI widgets such as tabbed frames, scrolling
frames, entry boxes, pull down menus, check boxes and radio buttons (a total of over 200
widgets). Therefore the user has to be ‘close’ to the PC. My customer wants his
customers to get access to a similar GUI over the internet. In this case, the users would get onto
the company’s internet site and go to a password protected area which had the product
design GUI. In both cases after the data has been entered a data file is created which is
used to create a drawing using a standard CAD package. In the internet based system a
pdf copy of the drawings will be e-mailed to the user. All the elements of both systems are
‘working’ except the GUI based data capture application for the internet based version.

Therefore I am trying to see how internet access and use of the product design system can be provided.

From the other two replies I can see that there are a number of possibilities which I think range from:
1. Having the current system (or something close to it) run in some sort of ‘shell’ provided by the company’s internet system to
2. Rewriting the GUI data capture part using applciations such as JavaScript, css, and cgi.

I suspect that the 2nd option would give the more ‘proper’ internet system. The downside is that this would need the larger development time.
One detail about the GUI is that it all the widgets are defined in a spreadsheet. Therefore I want
to see if the applciations used to create the GUI for the internet could use the spreadsheet
data to create the GUI. I have used the Tk grid packing method for the widgets which has
the very useful benefit that the widgets are automatically positioned (in x and y) initially
and as the widgets change size.

I can see I will need to discuss with the company’s internet provider the ‘shell’ option. In parallel
I am trying to see what the development route is for the ‘rewriting’ option.

I hope this answers the question from the anonymous monk.

You could do us a favor and use proper markup to make your posts readable.

And if you had been logged in you could correct it now right away...

Cheers Rolf

( addicted to the Perl Programming Language)