Saif

A couple of weeks ago a little misunderstanding about what GUIDeFATE was about led to an interesting comment. This tool had been designed to simplify GUI design using a text editor, and met the challenges of having a number of weakly supported potential targets to produce a semi consistent interface. Essentially producing a GUI for Perl applications has never been easy. A number of back-ends exist ( e.g Wx, Tk, Gtk, Win32, Qt etc) all with different approaches, most with rather outdated documentation, often not universally easy to install. A newbie like myself was never going to find this straight forward. So a tool was born that abstracts out the complexities of GUI design, producing near identical interfaces in multiple back-ends, all from a textual representation. As each interface was accommodated and announced, came reports of other folk being unable to use said interface, followed by a new module to use another GUI toolkit; so now we have a tool that can now accommodate 5 desktop UI systems.Surely that must cover all bases? Apparently not.

In response to a blog out-lining the difficulty I had had with the Qt paradigm of SLOTS and SOCKETS for interaction between the UI and application logic, and the need for a custom dispatcher, was a comment relating to WebSockets. Now GUIDeFATE was intended to be desktop UI focused, so clearly WebSockets are not the Sockets at issue. But Ron suggested I try out other people's efforts before re-inventing the wheel, thus finding this particular wheel rolling in a different direction. I started finding out about Mojolicious, Dancer, Catalyst. These are clearly the efforts of geniuses, with multiple dependencies and difficult to crowbar into an existing toolkit without duplication and “re-inventing the wheel”. I requested advice.

Flexibility is proportional to complexity

To connect to my less efficient brain requires much greater simplicity. So I quickly abandoned all these powerful frameworks. I chose the simplest possible websocket client, with the simplest available server, unashamedly ripping off the code from the examples provided. Attached them to quite possibly the simplest UI generator in the world... GUIDeFATE, of course☺. The result is GFweb.pm. A module for GUIDeFATE that generates and starts both the server and the client for a web-app-like interaction with a UI nearly identical to the desktop applications and with nearly completely unchanged programming logic. The extra effort required to transform a desktop app to a web application? Just change the small string selecting which back-end you want and the address/port to use.

my $gui=GUIDeFATE->new($window,"web","q");

The wheels come off..

Admittedly the tool keeps things simple: Only a handful of widgets, with limited interaction potential: hopefully just enough for a quick and dirty graphical application, simple enough for a noob like me with little knowledge of JavaScript or WebSockets. The reinvented wheel is decidedly wobbly. File selection and message boxes are not yet done...my problem is how to handle the client side responses which the server-side programming logic is waiting for to further process. I will figure it out, or somebody will point me in the right direction...it's inevitable. This experimental version is uploaded into GitHub. The applications need to be started in a folder containing the dependent files (preferably from a terminal) and popups need to be enabled (the application currently also starts a logging window to enable debugging).