App::XUL - Perl extension for creating deployable platform-independent standalone desktop applications based on XUL and XULRunner.
use App::XUL; my $app = App::XUL->new(name => 'MyApp'); $app->add( Window(id => 'main', Div(id => 'container', 'style' => 'background:black', Button(label => 'click', oncommand => sub { ID('container')->style('background:red'); }), ), ), ); $app->bundle(path => '/path/to/myapp.app', os => 'macosx');
XUL (+ XULRunner) makes it easy to create applications based on XML, CSS and JavaScript. App::XUL tries to simplify this even more by exchanging XML and JavaScript with Perl and providing an easy way to create deployable applications for the platforms XULRunner exists for.
XUL provides a set of powerful user widgets that look good and work as expected. They can be created with minimal effort and their appearance can be manipulated using CSS.
XUL is based on web technologies like XML, CSS and JavaScript. So anyone who is able to use these is able to create cool desktop applications.
Here is the homepage of the XUL and XULRunner projects at Mozilla.
The constructor new() is used to create a new application
my $app = App::XUL->new(name => 'MyApp');
The name of the application. Later also used as the application executable's name.
add() adds a window to the XUL application. The XML for the window tag and its contained tags is created using Perl functions. The names of the Perl functions used to create the XML tags corresponds to the tagnames, just the first letter is uppercase:
$app->add( Window(id => 'main', Div(id => 'container', 'style' => 'background:black', Button(label => 'click', oncommand => sub { ID('container')->style('background:red'); }), ); ) );
Keep in mind, that add will fail if the added tag is NOT a window tag. In XUL the root is always a window tag.
The first window beeing added is considered the main window and shown on startup.
$app->bundle(path => '/path/to/myapp.app', os => 'macosx');
This will create a complete standalone XUL application containing all XML code.
Some general information about XUL application deployment.
The systems currently supported are:
This creates the usual directory for a XULRunner based application containing all needed files, except the XULRunner executable itself. A start Perl script for various operation systems is created as well, e.g. you can start the application by executing the start_macosx.pl file for Mac OS X.
Note for Linux users: You have to add the directory containing the xulrunner (or xulrunner-bin) executable to your $PATH variable or adjust the start_linux.pl script accordingly. This is due to the fact that XULRunner for Linux us currently in beta phase and can only be used by unpacking it into a local directory.
Apple Documentation
coming soon
tbd. Either a *.deb or *.rpm Paket.
If debug is set to 1, a jsconsole is started together with the application which can be used to debugging messages. The default is debug = 0, so no jsconsole is started.
Events can be handled by attaching an event handler to an interface component. Event handlers can either be written in Perl or in JavaScript.
Here is an example of a Perl event handler that reacts on the mouse click of a button:
Button(label => 'click', oncommand => sub { # access environment and evtl. change it # ... });
Here is a similar JavaScript event handler:
Button(id => 'btn', label => 'click', oncommand => <<EOFJS); // here is some js code $('btn').update('Alrighty!'); EOFJS
JavaScript event handlers are executed faster than the Perl ones, due to the architecture (see below).
This refers to all activities within Perl event handlers that change the DOM of the XUL application. An example is the addition of another window, the insertion or update of a button label or the deletion of a style attribute etc.
Some things are important here:
The first step of changing the DOM is to get an element on which the changes are applied. The ID() function is used for that:
my $elem = ID('main');
The ID() function only works WHILE the application is running. Any changes to the object returned by the ID() function are transferred immedietly (asynchronous) to the XUL application/client.
my $child1 = ID('main')->child(0); my $numchildren = ID('main')->numchildren();
my $e = Div(id => 'container', 'style' => 'background:black', Button(label => 'click')); ID('main')->insert($e, 'end'); # end|start|...
ID('container')->style('background:red')->content(Span('Hello!'));
my $e = ID('container')->remove();
ID('container')->click();
ID('container')->oncommand(sub { # do stuff here # ... });
ID('container')->oncommand(undef);
None by default.
This chapter is meant for informational purposes. Sometimes it is nessessary to know how things are implemented to decide, for example, if you should use a Perl or a JavaScript event handler etc.
App::XUL is client-server based. The client is the instance of XULRunner running and the server is a pure Perl based webserver that reacts on the events that are triggered by the XUL interface.
Essentially all events are dispatched from XUL as Ajax calls to the Perl webserver which handles the event, makes changes to the DOM etc. The changes are then transferred back to the XUL app where they are applied.
Here is a rough workflow for event handling:
The communication between XUL and server is based on a simple JSON based protocol. The following syntax definition tries to define the protocol. Everything in curly brackets is a JSON object, strings are quoted and non-terminals are written within "<",">" brackets. The pipe symbol ("|") means "OR".
<CLIENT-REQUEST> := <EVENT> <SERVER-RESPONSE> := <ACTION> <SERVER-REQUEST> := <ACTION> <CLIENT-RESPONSE> := <STRING> <EVENT> := { event: <EVENTNAME>, id: <ID> } <EVENTNAME> := "abort" | "blur" | "change" | "click" | "dblclick" | "dragdrop" | "error" | "focus" | "keydown" | "keypress" | "keyup" | "load" | "mousedown" | "mousemove" | "mouseout" | "mouseover" | "mouseup" | "move" | "reset" | "resize" | "select" | "submit" | "unload" <ACTION> := <UPDATE> | <REMOVE> | <CREATE> | <QUIT> | <CHILD> | <NUMCHILDREN> | <INSERT> | <TRIGGER> | <REGISTER> | <UNREGISTER> | <SETATTR> | <GETATTR> <UPDATE> := { action: "update", id: <ID>, attributes: <ATTRIBUTES>, subactions: [ <ACTION>, ... ] } <ATTRIBUTES> := {<NAME>: <STRING>, ...} <REMOVE> := { action: "remove", id: <ID>, subactions: [ <ACTION>, ... ] } <CREATE> := { action: "create", parent: <ID>, attributes: <ATTRIBUTES>, content: <STRING>, subactions: [ <ACTION>, ... ] } <QUIT> := { action: "quit" } <CHILD> := { action: "child", id: <ID>, number: <NUMBER> } <NUMCHILDREN> := { action: "numchildren", id: <ID> } <INSERT> := { action: "insert", id: <ID>, position: <POSITION>, content: <STRING> } <TRIGGER> := { action: "trigger", id: <ID>, name: <STRING> } <REGISTER> := { action: "register", id: <ID>, name: <STRING>, callback: <STRING> } <UNREGISTER> := { action: "unregister", id: <ID>, name: <STRING> } <SETATTR> := { action: "setattr", id: <ID>, name: <STRING>, value: <STRING> } <GETATTR> := { action: "getattr", id: <ID>, name: <STRING> }
Here are some examples of client requests:
{event:"click", id:"btn"}
Here are some examples of server responses:
{action:"update", id:"btn", attributes:{label:"Alrighty!"}} {action:"remove", id:"btn"} {action:"create", parent:"main", content:"<button .../>"}
Mac applications are simply directories whose names end with ".app" and have a certain structure and demand certain files to exist.
This is the structure of a XUL application wrapped inside a Mac application as created by App::XUL (files are blue, directories are black):
MyApp.app/ Contents/ Info.plist Frameworks/ XUL.framework/ The XUL Mac framework MacOS start.pl (Perl-Script) Resources application.ini MyApp.icns chrome/ chrome.manifest content/ AppXUL.js myapp.xul defaults/ preferences/ prefs.js perl/ server/ server.pl modules/ All Perl modules the server depends on extensions/ updates/ 0/
The various files have specific functions. When the MyApp.app is clicked, the start.pl program is executed which then starts the server and the client:
Required by Mac OS X. This is the place where certain basic information about the application is read by Mac OS X, before anything else is done. For example, here the start.pl program is defined as the entry point of the application.
First program to be executed. Starts server and client.
Setups the XUL application. Defines which *.xul files to load, name of application etc.
Defines all Javascript functions used by App::XUL to manage the communication with the server.
Defines the basic UI for the XUL application.
Sets some preferences for the XUL application.
This starts the server.
tbd. Use NSIS or InstallJammer.
tbd. See Link.
tbd.
One thing on the todo list is to create a full-duplex connection between client and server so that the client can react on server events directly. This may be implemented using the HTML5 WebSocket protocol. For now all communication is iniciated from the client using AJAX calls.
This module actually stands a bit on its own with its approach. XUL modules exist though - XUL::Gui, XUL::Node and a few more.
Tom Kirchner, <tom@tomkirchner.com>
Copyright (C) 2011 by Tom Kirchner
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.10.0 or, at your option, any later version of Perl 5 you may have available.
To install App::XUL, copy and paste the appropriate command in to your terminal.
cpanm
cpanm App::XUL
CPAN shell
perl -MCPAN -e shell install App::XUL
For more information on module installation, please visit the detailed CPAN module installation guide.