Saif

Simple desktop applications are generally not what one considers a Perl specialization. Its expertise lies in generating processing and transforming textual data, hence its use in the web, and in tools like GUIDeFATE. This 'duct tape' manages to parse text, extracting relevant data, and absorbing information and producing a meaningful output efficiently. Displaying this output in a desktop application shouldn't be too difficult.

Challenge accepted

Not long ago I was inspired (by Ron Savage) to demonstrate ways of extracting data stored in databases with web front ends, merging contents of different sources of data and presenting it to the user, optionally making this data available offline in a local database. Should be possible to do this for the desktop user via graphical interface using GUIDeFATE. Specifically I wanted extract taxonomic information about plants, a field I have zero knowledge about. The Plants List is a useful resource with all plant species listed to anyone with a browser. Getting the list of all accepted and unresolved families and genera is trivial...use LWP::Simple and parsing the webpage form get ('http://www.theplantlist.org/1.1/browse/-/-/)' ) . From this, extracting species is a minor variation on the theme.

Wikipedia is another useful textual resource with images. From the genus or species being viewed, identifying any images on wikipedia is a mere case of generating a prospective URL, LWP::Simple::getting the source again, and using regular expressions to find the relevant section. I suspect that someone has a module that allows to navigate the HTML more elegantly rather than I have done, but as a proof of concept, this crude measure yields reasonable results.

All these can allow a simple desktop application to be developed using the rough and ready GUIDeFATE. The application allows you to search the entire Plants List directory, keeping a local cache of discovered data, and similarly searching for images from wikipedia (and keeping a copy of the images as well), to reduce the load on the respective servers).

Creating a GUI Interface

Straightforward using GUIDeFATE, of course making some allowances for the limited widget options.

use strict;
use warnings;
use GUIDeFATE;
# <  Initialise other modules and variables here >
my $window=<<END;
+-------------------------------------------+
|T The Plants List App                      |
+M------------------------------------------+
|  {Refresh Data} dd/mm/yy                  |
|  [                         ] {Search}     |
|  {Angiosperms  } 000   {Gymnosperms} 000  |
|  {Pteridophytes} 000   {Bryophytes } 000  |
|      No item on list                      |
|  +T-----------------+  +I--------------+  |    
|  |                  |  |               |  |
|  |                  |  |               |  |
|  |                  |  |               |  |
|  |                  |  |               |  |
|  |                  |  |               |  |
|  +------------------+  +---------------+  |
|  {<} {  Explore } {>}  { Upload Photo  }  |
|      0000 of 0000                         |
|  www.theplantlist.org     wikipedia.org   |
+-------------------------------------------+
END

my $backend=$ARGV[0]?$ARGV[0]:"web"; # allow command line backend selection
my $assist=$ARGV[1]?$ARGV[1]:"q";     # allow command line option selection
my $gui=GUIDeFATE->new($window,$backend,$assist);
my $frame=$gui->getFrame()||$gui;

# <  other code to be run before GUI activated  >

$gui->MainLoop()

# < rest of code >

Then adding LWP, websearch and data extraction, gives you an app like this.

Ducktaping the Web to a Websocket interface.

Well the real motivation for the initial challenge was to stop reinventing wheels that already work well, using clever tools like Mojolicious and other fantastic web frameworks. Can this work as a WebApp through GUIDeFATE? Apparently so, and in pure Perl. A few bugs apart, the webapp counterpart of the desktop application seems to work pretty much the same as the Desktop application. From GUIDeFATE version 0.11, setting the domain, listening port are both now possible, though still defaulting to localhost:8085. A new server is created which identifies an available listening port and a new client that survives losing focus. This makes it possible to have multiple different webapps being served and tested at the same time.

So there you have it. I am afraid there are still a few bugs to squash here, and most significantly I have failed in my attempt to rationalise the position of GUIDeFATE and its slave modules in a suitable namespace. But I will next aim to add a couple of more widgets..., web links, on/off buttons, check boxes and sliders are on my list, and I suspect these will be required for the last GUI back-end to be added to the already existing Wx, Tk, Gtk, Qt, Win32 and HTML/ WebSocket backends.