SetMan

[Łukasz997 124]

Good morning.

Programs Nobody Needs, episode twelve (or something around that). Long.

 

A story behind.

I would like to draw your attention to the short video attached. It shows how, using Fibaro’s “normal” interface and its ability to display SVG graphics, one can build a system for managing application settings - preferences.

I have seen user applications with a large number of configurable elements more than once. Their settings were changed using standard Fibaro UI elements: buttons, text fields or drop-down lists. Such an interface, however, quickly becomes extremely long and - in the applications I have seen - remains visible all the time. This is hardly ergonomic and effectively obscures information that is important “on a daily basis”.

That is why the idea of doing this without the above disadvantages started growing in my head.

I will leave it to you to judge how it turned out from the user’s point of view. The fact is that a surprisingly large number of settings can fit into a relatively small part of a typical screen - far more than with the standard UI.

 

 

The server and communication model.

A table library I wrote a time ago came to the rescue - except that it uses SVG rather than HTML. This approach was necessary mainly to obtain pop-up windows, which made it possible to create a compact and readable interface. In general, this library can perform “miracles” compared with HTML tables. The price is a larger data payload.

 

My previous experience with the client–server model, which had already worked well in the

Please login or register to see this link.

project, proved very useful here. The server and SVG engine was already there. Only one tiny detail remained - marrying the two together - so the work progressed quite quickly. 

SetMan, like TableMan, uses a client–server architecture. It collects commands from its clients and sends a dynamically generated, up-to-date image of the preferences directly back to them, without involving ANY client-side code. The server controls everything on the client, including button labels and their visibility. There is practically no communication protocol at all - it is a “fire and forget” model.

The exception is completing the editing process. Client application defines an onPrefsDone function, which the server calls after the settings have been confirmed. The function receives a table containing the editing result, and it is then up to the application to use those data.

The same function is used for reporting errors. In that case, the message is available in payload.result.error, while the error is simultaneously recorded in the server’s private terminal.

 

The server itself displays basic information about its clients. It detects deleted applications and communication from clients that have lost their subscription, for example after a server restart. It also allows dead subscriptions to be removed and clients to be restarted remotely.

 

The client.

A small Client module has to be included in the user application. It contains just... 34 lines of code (sic!).

That is perfectly sufficient. The Client is a complete idiot. It validates nothing and calculates nothing. Apart from the UI-handling functions for the buttons, it has only three functions in total: register, new, exec. 

The last one is used to send preference definitions and actions performed by the user - button presses - to the server. An application can have several different preference sets prepared and replace them dynamically. At any given moment, however, only one set, one UI field and one group of buttons are active.

 

The preference definition is an ordinary serializable Lua table. "Construction language” is quite compact. For example, the settings shown in the video take about 100 lines, even though they include numeric ranges, single and multiple selections, switchable rows, separators and pop-up windows.

There is many taht can be configured. Among other things, one can specify:

• type of each item,
• number and width of columns,
• keys of returned values,
• range, step and unit of numeric values,
• different increments for short and long button presses,
• single and multiple selections,
• section separators,
• behaviour of switchable rows,
• size and position of pop-ups,
• selected interface colours,
• the initial cursor position.

Not everything has to be defined. There is a set of defaults which produces the appearance shown in the video.

What I personally find attractive: in “inactive” state, only one MENU button remains visible. Pressing it expands the preferences view and reveals the remaining buttons. Their labels change depending on the current operation: navigation, value editing, selecting from a list or confirming changes.

Once editing is complete, the entire preferences interface disappears again and the application receives the final result.

Does anybody need it? Probably not.

But after all, this is the “Programs Nobody Needs” series.

Part of code defining example in video:
 

Please login or register to see this code.

 

Edited 1 hour ago by Łukasz997