Fl_Remote 0.1

Code for examination of concept "FLTK headless". The code is based on FLTK 1.3.4 release.
Download [ Fl_Remote_0_1_0_1.tar.gz ]
For execution of the software it is necessary to patch the FLTK and recompile/reinstall it. There is a little change to Fl_Group, that allows to retrieve the widget that is currently drawing. Details are provided in directory FLTK_Patch of the Fl_Remote release.
Bugfix Update of "FLTK_Remote_Patches_to_Fl_Group.txt" because text was not complete and also the patched files now are included.

The idea is to enable most of the existing FLTK applications to be used by a network connection, just by linking them to another FLTK core.

The primary difficulty is round trip time of inputs and events and the amount of data at all.

Anyway this won't be as fast as a local application, but the question is - could it be fast enough to be a useful FLTK feature?

This is experimental code not a usable application. It should work on most systems*, but not for sure between computers, because there are binary data without regarding endianess of the machines. So in the network a connection may work or not.  The software got much more extensive than expected, but also proved to be a very interesting challenge and now it is your part, to play with it. ;o)

* in the moment it is Linux only, because for MS-Windows the server crashes on drawing with new Remote_Graphics. There seems to be some unexpected offscreen drawing or copy_surface, very hard to debug. So for MS-Windows the software is restricted to copy of local window, without providing drawings.

I'm sorry, there is just the source code and doxygen documents, no makefiles. I'm used to push things to my IDE, some setups and it works.


FLTK must be included to all projects, header files and library


#define nullptr=0    // this is necessary to build
#define DEBUG    // this prints debug output


Please use "fltk-config" to get the settings that match to your system:

    fltk-config --cxxflags

    fltk-config --ldflags

    The programs must be linked to libFl_Remote_Lib, libfltk and all its dependencies.

The concept of the code is to cut the FLTK into a POSIX server side without graphic card ("headless", e.g. an embedded system) and a FLTK based client side, that shows the windows.

The approach to cut the FLTK are the drawing orders and the events:

To realise the drawing orders on client side, the structure of the local window will be copied to the client, when the client opens the connection. The client uses this information to setup the local window and represent the server widgets by Fl_Remote_Widgets.

On server side the Fl_Remote_Surface will be set and the drawing output of FLTK software is changed to remote commands, they are sent to the client and committed to the Fl_Remote_Widget that represents the widget the drawing comes from.

The Fl_Remote_Widget collects these drawing orders and uses them for local drawing. It is possible to send one copy of all drawings at start to show a static copy, that is able to draw itself.

To the other direction the Fl_Remote_Widget sends all events that are committed to it. It is possible to run this with standard return codes and with return code queried from the server (round trip).

The system integration is very poor, but this example shows the basic implementation of this idea and points to ways how to speed things up:

Some drawing commands (fl_width, fl_height) ask for settings and sizes of local drawing and need a round trip. But it is also possible to retrieve these values from local settings and unique requests to speed things up.

The events sometimes appear much to fast for round trip, this example allows to activate this, but it doesn't work well. Maybe some of the events may be prevented from round trip by doing lazy evaluation - when different from default this will be sent and make the client react like after a direkt answer. Also the Fl_Remote_Widget may memorise the current answers to use. But inputs and new drawings most often will need a round trip.

This implementation is provided to find out, whether it is possible to operate existing applications by remote client, or whether this approach fails regarding to more complex FLTK functions. So there is not a single issue or question, but someone who knows FLTK better than I, should take a look to the code. In the moment there is a very poor FLTK integration on server side, because I don't know about the FLTK core details. Also on client side the redrawing doesn't work smoothly, sometimes all is fine, sometime the drawing seems to be overwritten.

Fl_Remote_Surface::eval_event, Fl_Remote_Client::cb_event and Fl_Remote_Graphics_Driver::chk() are the parts with most problems.

Ideas and comments?