Re: Webbased look and feel in Perl/Tk

I believe that the other replies have misinterpreted the question. The idea does not, to me, seem to be to rewrite the interface for the Web but simply make it look that way, while maintaining its Tk-ness underneath. Not knowing much about Tk, I can't help much with that, but -- juo: knowing what sort of application you're writing would help. And which interpretation (or neither?) is correct?

convert((post(POST_CURRENT))->value,
                 CONV_ZORKMIDS, CONV_DOLLARS) == 0.02
[download]

Comment on Re: Webbased look and feel in Perl/Tk Download Code

Replies are listed 'Best First'.
Re: Re: Webbased look and feel in Perl/Tk by juo (Curate) on Aug 22, 2001 at 04:26 UTC
Correct, The language behind the look and feel does not matter. It is only the look and feel that has to be webbased. The reason for this is that many different applications are used who are all using their own different codes but are used in one workflow by one operator : Some use Perl, some use Java, some use Tcl/Tk, some use some other application owned languages, etc.... but the common wraparound (GUI) for those applications should be a webbased look and feel so that the operator is guided through the different applications in the same look and feel. In that way the different applications are wrapped around one GUI which makes the use easy. Today were soo many applications can be used to achieve target automation is an important factor but besided from automation ease of use is the next important factor and the only way this can be achieved when using different applications is try to wrap them around one GUI that guides the users through the different steps, through the different applications.	[reply]
Re: Re: Re: Webbased look and feel in Perl/Tk by premchai21 (Curate) on Aug 22, 2001 at 05:38 UTC
Your operator(s) should be intelligent enough to figure out that the same controls do the same things, in that case. There really is no one HTML L&F -- it's dependent on the browser, OS, toolkit (in some cases), and possibly other factors. If you *really* need to have a common look and feel, then find a UI toolkit, plaf (for Java / Swing), and/or customization set, whichever happen(s) to be applicable, that is interfaceable to every system that needs to have a UI. Another alternative is to simply write the UI into one separate frontend, then put the other programs behind some sort of command line interface and use pipes (same box) or sockets (different boxes). Just my 2%$USD...	[reply]