BUU has asked for the wisdom of the Perl Monks concerning the following question:

Inspired by the recent spate of meditations on this subject, I knocked together a very, very sketchy script. So far using the script looks something like 
my $h = HTK->new();
HTK::Text_Field->new($h,'test');

$h->main_loop;

[download]
And it would open a browser and display a text field containing 'test', and theoretically respond to use events and so forth.

How ever I've already run in to one problem: good old server push, namely the server can't send data to the client unless the client requests it. To solve this I create an invisible frame that refreshes itself every second. Then I can simply send a small bit of javascript to this hidden frame that causes the main frame to reload itself. Already I'm getting in to portability issues having to use javascript.

Thats not really why I'm writing this though. Why I'm writing this is two fold:

A) Does this have any practical point? Would anyone actually use this for something? Is the cross-platform abilities of html worth the lack of "gui power"?

By gui power I mean that in html there are really only two ways to receive events, one is you click on a hyperlink and the other is that you click a 'form submit' button. There are of course other issues related to this.

You could implement certain other features with javascript, but if you end up writing such complicated and probably non portable javascript, whats the point in using html as a gui, why not just use gtk or something?

B) Assuming "yes" to A, is the interface any good? Should I stick with trying to mimic other gui tool kits or would it be better to hand craft the html and then have the program try to guess which events it needs to receive?

Replies are listed 'Best First'.
Re: HTML as a GUI: part 32,523rd
by dragonchild (Archbishop) on Apr 09, 2004 at 12:12 UTC
    IE is the most common GUI platform out there. It is also the easiest platform to write for, at least for me, given that it's what I do for a living. (I write webapps on Unix to be viewed by IE6.)

    My meditation on the subject (which seems to have kicked this spate off) wasn't intended on using IE as a replacement for Tk or any other GUI toolkit. I wanted to know the following things:

    1. Is this even possible?
    2. Is this practical?
    3. Are there any major holes this would expose?
    4. Are there any major holes this would be using?

    The reason I wanted to know it was to create very small applications (utilities, really), primarily for myself and my wife. One of my major annoyances with my life is that I have Win32 at home, work on Unix, and can't meld the two. I can't really change the Win32 and don't have the time to get a stable LAMP box running. This would be an ideal compromise, in my mind.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

[reply]
      Why did you reject the concept of running a small perl based mini-web server and reject connections from 127.0.0.1? Then this cross-platform nature you are requesting would truly be achieved. Now, you're using an IE-ism that may not always work.
[reply]
        I haven't rejected anything because I haven't had time to try anything. My goal is to make it as easy to use as possible, without depending on Windows to keep my server up. If I can launch the webserver and IE and point it to the right page, all in one click ... perfect! If I can't, then I need to find something that will.

        Remember - my wife needs to be able to use this and she will refuse if it requires more effort than Quicken (or any other Win32 app).

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

[reply]
Re: HTML as a GUI: part 32,523rd
by xdg (Monsignor) on Apr 09, 2004 at 12:10 UTC

    My opinion on (a) is that this is probably more trouble than it's worth. There's a huge push to make all UI "browser-based" -- but frankly, browsers aren't well designed for truly interactive GUIs and aren't all that compatible from platform to platform either, so you have compatibility issues no matter what you do. As I see it, the browser as interface has only a couple things going for it:

    • A browser is pretty much guaranteed to be installed on most modern systems
    • Users know how to work them (usually)

    If you really need a more interactive GUI interface, then I think that java is the way to go since it was explicitly designed for the task of providing a platform independent gui. Yes, it has some quirks, too, but I think a lot fewer. And some version of it is also now likely to be installed on many modern systems. (E.g., Windows)

    And for those of us who just can't give up perl -- which of course we don't want to do -- why not combine the two with Inline::Java. The 2003 Perl Advent Calendar has an article on Using Java as a perl GUI that shows how this might be done.

    -xdg

    Code posted by xdg on PerlMonks is public domain. It has no warranties, express or implied. Posted code may not have been tested. Use at your own risk.

[reply]
      There's a third benefit. In most complex programs, the engine is 10-20% of the code and the UI is 80-90%. Contrast that to most web applications, where the ratio is flipped. Flipping this ratio has another huge benefit - the LOC drops dramatically and time-to-market is cut in half (or more).

      By using the browser as a UI, all I (as the developer) have to do is generate well-formed DHTML. Since I'm targeting a platform (IE, NS, MZ, whatever), I can even tailor my code to that specific platform. If I want, I can play nice, but I don't have to. Since the code is installed on the user's machine, it's more acceptable for the code to be tailored to that specific setup.

      Yes, the goal is to flip the standard paradigm of DHTML. *shrugs*

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

[reply]

      browsers aren't well designed for truly interactive GUIs and aren't all that compatible from platform to platform either

      On the contrary, there are a lot of developments that make browsers great for interactive GUIs. The problem is that most of them are specific to the browser (ActiveX, XUL, JavaScript, etc.)

      Java is not the solution here. Applets are largely considered a failure (even though they were one of the orginal big reasons to use Java). Swing and AWT are too bloated and kludgy, even when compared to the rest of the Java API. Java found it's niche on the server side--exactly opposite from where Sun orginally wanted it in the 1.0 release. Oh, and cell phones, which are actually the sort of devices that Java was orginally targeted at back when it was called 'Oak'.

      ----
      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

[reply]
[d/l]
      I'm not really into Java at all, just sort of speaking off the cuff, but aren't there some compatibility issues between Java implementations? Mainly Microsoft's Java and Sun's Java. This may not be any sort of issue with what you are describing, but I have seen something of the sort cause problems in the past. Mainly, a Java app (using Sun's Java) not playing nice with MS's Java when we attempted to run the app on a server (so it wouldn't be tied to a workstation). Ended up we had to run it off a workstation where Sun's Java could be loaded. Just sort of tossing out my 2¢. :-)

      "Ex Libris un Peut de Tout"
[reply]
        My coworkers ran into the same thing, but between 1.2 and 1.4. I wouldn't trust Java impementations farther than I can throw them.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

[reply]
It's called OpenThought
by PodMaster (Abbot) on Apr 09, 2004 at 22:42 UTC
    It seems to me that you're reinventing OpenThought. If I were you I'd stick with OpenThought, but that's just my need to re-use.

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
Re: HTML as a GUI: part 32,523rd
by theAcolyte (Pilgrim) on Apr 10, 2004 at 00:23 UTC
    Actually, using the Browser as UI can make developing the UI easy -- if you're already used to doing it. If you are -not- worried about cross-platform issues, then its -- to me -- ideal.

    IE is installed on all windows systems ... it has to be for the Windows Explorer.

    IE lets you create things called .hta (hyper-text applications). You can call DLLs and other operating system bits from your hta's. You can embed perl (perlscript, via activestate). You can easily ditch *all* the browsers native chrome and just use an empty window as a starting place. You can create components with defined behaviors (via .htc files) that are easy to reuse.

    No, I'm not a big MS fan, but I have used IE as interface for desktop based, custom, windows apps. Hit MSDN and start reading about IE ... you'd be amazed at how much they've done to make this easy and powerful for you. I think few poeple take advantage of it because .. its 1 platform and its microsoft. I don't blame 'em.

    - Erik

[reply]

Back to Seekers of Perl Wisdom