Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

A different approach to generating a GUI

by qbxk (Friar)
on Dec 28, 2005 at 21:38 UTC ( [id://519648]=perlmeditation: print w/replies, xml ) Need Help??

So, this is a concept I'm toying with (and I think it can become quite sophisticated in time) - but besides the fact that I implemented it in perl (why not?) it has no other real association with perl, as it could be done with just about any language.

So the concept, which after several attempts is proving harder to explain in prose than I had imagined it would be, is essentially writing your GUIs in HTML/JS and wrapping your code (virtually any perl code) in a mini web server to communicate with it through your browser. With this approach you instantly have a 100% cross-platform, GUI app. As long as the user has a browser (that's compatible with whatever JS you need to use) they can get the GUI for your program. The possibilities are endless, it strikes me that this is probably a good approach for writing GUIs for code running on "embedded devices" as well.

The module I've written to encapsulate the heavy lifting of an approach like this I'm tentatively calling ServerApp (though, other suggestions are welcome) - it's posted in the code section, there's also a (primitive) testing suite that I have not posted... However, my first program using this as a foundation can be used as a font previewer, it wants for more features, but is cool as-is: FontPreview

I'm posting this to initiate a discussion on several things relating to this concept:

Generally:
- is this a good idea?
- has this been done before?
- how can this be made more secure?

Specifically:
- I'm not a CPAN author (yet?), if this concept proves useful I would encourage people to assist me in bringing it to the repository
- Queries (GET/POSTs) to the ServerApp need to spawn new threads so that it can respond to several simultaneously should that need occur. I think there should also be an option to call your ServerApp->run_with() method asynchronously. I want to ensure that this is done correctly and portably (as one of the goals of the project is providing easy cross-platform GUI development), can I request some expertise in this area? (spawing threads/forking portably, etc)

Replies are listed 'Best First'.
Re: A different approach to generating a GUI
by renodino (Curate) on Dec 28, 2005 at 23:29 UTC
    Different ? Yes. New ? No.

    The missing piece is a nice API to handle all this, and maybe a framework. Oh, then some XSLT to transform XUL <=> XAML. ;^)

    It also likely requires a well formed MVC architecture for the application.

    BTW: There was an attempt to provide a pTk style mapping for XUL, but it seems to have "withered on the vine".

    Some resources:

    I'd love to be able to apply all of that, but the lack of a single coherent API to support it makes it a bit difficult (tho XUL::Node might be a start). As to how a server app should behave, I suspect that trying to route everything thru the usual Apache/mod_perl channel might be difficult; you may want to consider HTTP::Daemon. As to threading/forking, I'll offer Thread::Apartment as a possible (albeit immature) solution.

      I suspect that trying to route everything thru the usual Apache/mod_perl channel might be difficult; you may want to consider HTTP::Daemon.

      right - embedded server, ServerApp.pm has a "use HTTP::Daemon" as it's 3rd or 4th line

Re: A different approach to generating a GUI
by johnnywang (Priest) on Dec 28, 2005 at 22:19 UTC
    This approach, using browser as a general GUI framework and shipping with an embedded server, has certainly been used before. I'm not sure whether there have been any established general framework, or whether this is really different from any web application.

    There are certainly some limitations for this type of application, it needs to be web-like (e.g., pretty difficult to write a drawing app). The recent talk about AJAX (as exemplifed by gmail and google maps) certainly make this approach more like a desktop application.

    Futhermore, the GUI framework in Firefox is another nice approach (XUL and javascript), not just for firefox extensions but as a general GUI framework.

Re: A different approach to generating a GUI
by Errto (Vicar) on Dec 29, 2005 at 05:08 UTC

    So I suppose I should chime in since my one huge Perl project at the moment is a desktop app that works precisely this way. I got my inspiration for it from the node GUI with HTTP::Daemon and I have to say that while I was poking at it the one thing that struck me was, wouldn't it be good if there were an API for this. Tomorrow when I get in I will see how well this API matches my program structure and hopefully that will give me the basis for a more useful reply.

    Regarding threads, I've played with threads once or twice during the lifetime of this particular project, and so far the benefit isn't really hitting me. The only clean way I can think of to use threads is to simply start off by spawning two threads, one to handle the HTTP::Daemon loop and one to do any work not directly related to generating the response. I don't think spawning a thread for each request will be good because it's too much overhead.

    In terms of security, the most important thing is that you listen only on localhost, which you're already doing. You could also try generating a magic key to go into the query string like Google Desktop does, but I have not yet figured out what the security benefit of that is.

    And don't forget, this may be cross-platform but an application developer still has to deal with the issue of users actually having Perl. For applications, you might want to use PAR to package executables for the platforms the app needs to run on.

Re: A different approach to generating a GUI
by toma (Vicar) on Dec 29, 2005 at 02:24 UTC
    I have been using this approach in various CAD applications for the past seven years or so. Mostly I have used it in unix, but also win95/98/2000/XP.

    The good part is that it is easy to integrate your application with other web content. It helps to have an application that naturally integrates with a web site that your users already really like.

    The bad part is that it is hard to make a really slick GUI without using a lot of browser-specific code. Recent javascript library development (AJAX) should make it easier to support IE and Mozilla. This hasn't done me any good so far, since my apps still support Netscape 4.72 on HP-UX.

    It can be difficult to get users to install client software. If feasible, I usually favor a conventional web application.

    It should work perfectly the first time! - toma
Re: A different approach to generating a GUI
by dimar (Curate) on Dec 29, 2005 at 05:42 UTC

    It's sort of an open secret that your 'different approach' is variously frowned upon by various interests for various reasons. It's not to say its a bad idea. Even the old test of "can I write a drawing application in it" is becoming more and more feasible with what we commonly call a 'web browser' ... The real question is whether it will catch on and outshine the wxWidgets and DotNets of the world, until the next "paradigm shift" in GUI programming comes along.

    see also: Bindows and API War (search for "HTAs and DHTML") for some additional perspectives.

    =oQDlNWYsBHI5JXZ2VGIulGIlJXYgQkUPxEIlhGdgY2bgMXZ5VGIlhGV
Re: A different approach to generating a GUI
by dragonchild (Archbishop) on Dec 29, 2005 at 01:13 UTC
    If you can guarantee that:
    • Your users will only use IE on Win32
    • Your users will install ActivePerl
    Then, you can use PerlScript to build a full webserver within the webpage itself. There's been some ideas about this floating around the Net for at least 5 years now. But, because of the restrictions I outlined above, this is only useful for some intranet application. So, the idea never took off.

    As for security ... what avenues of attack do you foresee? The big question is "Do you have anything going over a wire?" If you don't (and loopback doesn't count), then you don't need https, which is good because it's a pain in the ass to implement and/or deploy. (There's a reason why Apache uses OpenSSL instead of writing its own.)

    As for using the browser as your GUI ... I wouldn't. Browsers right now suck ass as GUI environments. The only benefit they have is that a monkey can do something that looks okay. To get anything seriously good, you have to move out of the browser and into a real GUI environment like wxPerl or Tk. To me, the measure of a GUI environment is "Can you implement FreeCiv?" If you can't, then you're not a real GUI environment. Browsers are coming close, but they're not there yet.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: A different approach to generating a GUI
by zentara (Archbishop) on Dec 29, 2005 at 11:26 UTC
    As far as browser-based guis go, I tend to think of the opposite direction, that is making a browser plugin that would allow a limited Perl and a limited Perl/gui module to run in the browser, not on the server. Like the Java Browser plugin, but for Perl. We could do lines, curves, animations , etc, like they do with Java through the browser. I wish I was smart enough to make a really functional browser plugin.

    Another option is just to drop the browser all together, and make your gui server just send control signals and data to pure Perl GUis directly through sockets.

    That is already the easiest thing to do. Just have your users download the special client programs, and let them connect. Why have the overhead of the browser at all?


    I'm not really a human, but I play one on earth. flash japh
      Why have the overhead of the browser at all?

      Because everyone pretty much already has a browser installed on their desktop, and they're already familiar w/ navigating inside the browser. And, at least for Firefox (and maybe Opera), the browsers have already solved much of the platform/OS compatibility issues.

      GUI tookits, OTOH, - and esp, in my experience, Perl GUI toolkits - tend to have mixed success addressing the platform independence requirement.

      I think some of your assumptions wrt browser capabilities may be a bit dated; XUL brings much functionality to the Firefox browser, and when XAML becomes "official" in '06(?), it will likely further change user expectations wrt browser capabilities.

      Hence, the need for "plugins" may go away, and by writing MVC structured apps - w/ very loose coupling between the M and the V -, GUI apps become small local web servers, at the same time providing the option for remote execution for apps that need it. Whether the user needs a Perl - or Java or Python or C# or etc. - installation on their desktop will depend entirely on the complexity of the app, and the speed of their 'net connection (tho the security issues remain problematic).

      So, wrt the OP, it would be nice to have a decent Perl API in development now to address the likely future transition to browser based GUIs, even if the widget set were limited to XUL/Firefox for the time being.

Re: A different approach to generating a GUI
by BUU (Prior) on Dec 29, 2005 at 08:48 UTC
    I suppose this is a bit flamey, but I have a serious question. Has anyone reading this *not* thought of this?
      hehe - yah, well i said it ;)
Re: A different approach to generating a GUI
by westernflame (Sexton) on Jan 06, 2006 at 19:24 UTC
    I agree that using web browsers and a form of embedded server has a lot of potential. However, the possible approaches always seem far to polarised. You either have to much running in the browser (PerlScript) and to little access to the system. Or an embedded server that has all the access to the system it needs but having to rely on ajax or page refresh just to change a DOM element. An alternative would be to use a flash object as an intermediary. Flash is able to execute JavaScript, and create asynchronous connections to a server. This would enable you to execute JavaScript in the browser, and interact with the DOM, directly from Perl. Event handlers could be automatically added to HTML elements, sending events to be handled in Perl. Moreover, the user would only see a static html file on their local computer.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://519648]
Approved by johnnywang
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (7)
As of 2024-03-28 21:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found