An introduction to Pliant UI (graphic mode user interface)

Single paragraph description

Pliant language is one language for doing everything.
Pliant UI is one user interface for doing everything.
So, it's greatest advantage is to avoid you to choice between a web interface for you application (with all the limits and maintaining issues due to web browsers poor interactivity and predictability), and a classical graphical toolkit (like Trolltech Qt) that fits poorly the client server model. Well ... it should.

Now, from the data point of view. The current mainstream offer is split in two extreme solutions: on one hand databases are very rigid (same fixed set of fields for each row in a table), and on the other hand desktop applications (word processor) are mostly uncontrollable (the server receives a file in the end without the ability to restrict on the fly the user producing it, and with a so complex file format that post processing the file is mostly not possible for any non trivial operation). Pliant UI bridges the gap: it is possible to design some short specialized desktop applications properly integrated in the middle of database centric applications that will enable the user to enter desktop data through a specialized user interface that grants that the output format is simple (specialized for the task), so that post processing the data is possible.

Design choices

There Pliant UI graphical user interface has several interesting properties:


The Pliant UI always works in a client server model. The client and the server may run in the same Pliant instance, or in two Pliant different Pliant instances or logical computers on the same physical computer, or on two different connected computers either on the same lan or connected through the Internet.


Any application is mapped to an URL or a set of URLs.


The set of instructions available to the application has been designed to free the server from all rendering related computations, as opposed to application computations. This is just like HTML, as opposed to X11 where positioning and widgets handling is on server side, and it greatly helps provide good server scalability for database centric applications.


The drawing capabilities (we are talking about general capabilities, not format details) will scale up to both VNC (bitmap model with minimal yet efficient incremental updates) and most PDF (high end 2D vector drawing). MP3 and MPEG2 multimedia will be supported at some point. 3D (OpenGL) will not be supported so that server side rendering is required in this area, on top of either bitmap or MPEG2 encoding to send the result to the browser.


No scripting language is used on the client side. A client side scripting language enables better response time over a high latency connection, and would have been easy to provide since Pliant is a dynamic compiler, but is a bad idea in facts because then a complex application requires both the server and the client to run the right version of the environment, but most of the time you have no control on the client side updates. It also enables a much wider spectrum of attacks on the client so that properly securing the client gets an order of magnitude harder (assuming the core browser language is just like Pliant (as opposed to C) not too prone to stack buffer overflow).


The protocol between the client and server has been designed to cope optimally with a high latency connection between the client and the server, within the limit that no code provided by the server is executed on the client. This has been achieved largely through making the protocol asynchronous.


The windowing system is very constrained so that no mouse is required. Basically, there are five windows: left, right, top, bottom and center. The right window is assigned to the windows manager so cannot be used by the application. The left window should be used for application menus. The top window is intended to display pop up content, and the bottom one to display status.
The Pliant UI browser provides a session notion which is close to modern web browsers tab notion. Also, when several sessions need to be displayed at once, as an example to display several documents at once, the center window can be split among several sessions. Only side windows associated with the currently active session are displayed.
Some people will like this layout mechanism because you never need to move or resize a window, some will not because you cannot organize your screen freely: the application does it. It goes as far as the size of side windows adjusts automatically according to their content size.

As a summary, and in very few words, the Pliant UI is a bit like the web HTML/HTTP, with no scripting language running on the client, and better designed instructions and protocol so that very interactive applications are easier to write, and if needed, precise rendering relies on sane foundations.

The 'Pliant graphic stack machinery layout' is more technical, but still related to design choices at user interface level, so you can also read it as an extension of this introduction.

Web compatibility

A Pliant HTTP proxy is provided that translates the Pliant UI protocol to HTML/HTTP and Javascript (also named AJAX nowadays), so that an application written using the Pliant UI user interface can be accessed with no modification from a standard web browser. Anyway, the HTTP proxy does no miracle, so it works great for a simple looking database application, but does not work for a very interactive applications such as word processor.

A Pliant VNC proxy is also provided that translates the Pliant UI protocol to VNC protocol. VNC clients are available on virtually all not too old platforms. The drawback of VNC is that it consumes more bandwidth and is more sensible to connection latency, but the advantage is that the translation is 100% accurate so that any Pliant application written using the Pliant UI graphical interface will work perfectly when accessed from a standard VNC client though the Pliant VNC proxy.


As far as code maturity is concerned,
The Pliant UI is now production quality for database centric applications, but advanced drawing and multimedia features are not finished yet.
The client stands on Pliant bitmap and 2D vector libraries that have very strong design, capabilities, and stability.

Keys management (to provide secured connection between the client and the server) is also still too heavy to handle from the administration point of view.

The stability and scalability of the HTTP and VNC proxy is still not known because they have not been tested intensively enough.

The UI styling model is weak, but I start to have doubts that a strong and efficient one be possible.

On the down side, I will probably not try to provide maximum compatibility for UI clients and servers running different releases of Pliant in the next few years because it would bring huge constrains on the development so does not worth the effort since Pliant is not currently widespread.

Summary, what is it good for ?

If you plan to write easily a database centric application and you prefer simple code and users great productivity to jukebox like looking, then Pliant UI is for you. You will get web access as a bonus.
On the other hand, if you plan to do a look appealing web site, using plenty of web rendering tricks, then don't go with Pliant UI + Pliant HTTP proxy because tricks would be much harder to insert in your pages than with lower level web only tools such as PHP.

If you plan to write a more graphical application (image editor, word processor) you may get troubles due to the fact that the highly graphical features are not finished yet. So don't do that right now, unless you are ready to experiment, and maybe contribute.


What about the old Pliant HTTP server using .page instructions set ?

It is dead code. Don't start any new application relying on it.
The Pliant UI + HTTP proxy just proved to be a better solution in most situations because it better solves many of the complex issues related to the web HTML/HTTP protocol (session notion, partial page change, precise server side rendering, everyday users productivity) so enables cleaner code and better interactivity ('hook change' instruction).

I would like to use Pliant UI as my application GUI, but I don't want to use Pliant language for writing my application.. Is it possible ?

You would need to write a server side library for your favorite language that will send PML encoded instructions to the Pliant UI client. For Pliant language, this is implemented in /pliant/graphic/ui/server/api.pli
Writing such a library in another language is probably not very hard, but properly implementing 'button' and 'section dynamic' semantic (lazy execution model) might not be possible in many well known languages without a lot of extra glue code in the application due to the lack of meta programming at language level.