Code for examination of concept "FLTK headless". The code is
based on FLTK 1.3.4 release.
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
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
Bugfix 0.1.0.1: Update of "FLTK_Remote_Patches_to_Fl_Group.txt"
because text was not complete and also the patched files now are
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
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
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
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?