about graphics and GUI

[Luc Taesch]

>>
>>
>> A drawback with using GS as a frontend to a Qt backend is that we
>> can't design our GUI with the graphical GUI builders available for
>> Qt. Maybe the idea of having an interface, like GS, to a GUI library
>>
>> in Erlang isn't a good idea at all. You can write the GUI in C++ and
>>
>> communicate with Erlang at the application level instead. This of
>> cause require that you define your own communication between the
>> Erlang application and the corresponding C++ program and the fast
>> start up development time using GS is lost but it is something to
>> consider.
>
> the standard would be the protocol then, rather than the interface. ?
>
>>
>

it seems its the approach taken by kde2  /based on qt 2,2), and the dcop
approach
see
http://www.arrakis.es/~rlarrosa/tutorial/p5.html
tutorial taken from,
http://developer.kde.org/documentation/tutorials.html

typically, one program define the ui (or even dynamically load it from
xml), and the server has just to implement a series of DCOP slots
(functions).

the server can be in other languages, and an example of python biding is
given as an example.
http://www.arrakis.es/~rlarrosa/tutorial/p6.html