[Customdrawn] Replace some widgets

[Michael Schnell]

On 04/05/2012 10:46 AM, Giuliano Colla wrote:
>
> Depending on what are your needs you have at least three ways to go:
>
> 1) If you just want a remote GUI, i.e. your application running on 
> computer A and display, keyboard and mouse on computer B, you don't 
> have to change a bit, because Linux and X11 already provide all the 
> facilities to do that: just use a remote X server, and you're done.
During the last four  years I did a lot of research on this issue, and 
so I of course do know how X11 works (VNC is another option). But here, 
the Widget Set, Window Manager etc needs to run on the non-local-GUI 
device, which might be a very limited embedded thingy. This is why I 
searched for possibilities that move the memory and CPU hungry stuff to 
the remote control unit.
>
> 2) you can start a full new widgetset, maybe taking the nogui 
> widgetset as a starting point
At that point in time, I did this. But this asks for implementing an 
event queue (e.g. for handling Timer- and Thread- generated events). And 
here I decided that it is very inappropriate to do yet another new event 
queue implementation, while all other Widget Types already do have this 
code. I also considered to drop Lazarus and use mseGUI. Same does 
provide a decent Event Queue enabled  "Widget Type" that has no GUI 
binding. And based on this all GUI enabled "Widget Types" are implemented.
>
> 3) create your branch among the backends of CustomDrawn, and implement 
> what you need.
I still do hope, that CustomDraw might have (or get) such a hook. I 
understand that (similar to fpGUI) there are multiple "backends" (such 
as X11, Android, ...) that implement the low level stuff, based on what 
facilities each backend might provide. So it should be possible to add a 
new backend without forking the project. Here I feel, that the way fpGUI 
works (using a compiler define to select the backend when compiling), is 
very appropriate.

Of course some backends will need an event queue done in Pascal code 
(e.g. if it is not possible to feed events (e.g. generated by threads) 
to the event queue that might be provided by the GUI API, an Event queue 
needs to be implemented in Pascal, that needs to be synchronized (i.e. 
fed by or alternately fetched from) with the event queue the GUI API 
might provide. As this is an ubiquitous issue, it does make sense to 
implement the event queue outside of the backend code, and thus make it 
usable for all current and upcoming backends.

Michael