about graphics and GUI

[Kent Boortz]

I will try to answer, maybe someone else can fill in.

> 1) when using toolbars, say table monitor, we can see the "graphics
> initialising" which take a while.  is the delay it due to the
> erlang, or some lib ? is it using tk, or gs ? where are the
> ineffcencies coming from ? (no flamewar intended )

I can't say what is taking the time but the GS library is very
inefficient. Lots of strings are sent from the Erlang node to an
external OS process.

But I can't repeat the problem, my home machine is so fast I don't
even see a the dialog you talk about ;-)

> 2) is it possible to integrate erlang with c++, or c only ?

How do you want to integrate Erlang with C++? CORBA and other "high
level" integration is no problem. ERL_INTERFACE is written for C but
has the usual

    #ifdef __cplusplus
    extern "C" {
    #endif

to make the functions callable from C++. Even the header file for
writing Erlang linked in drivers is adjusted to work for C++.

But here are no classes for Erlang and C++ integration that I know of.

> 3) Qt libs is now under GPL. would it be interesting to use it as a
> multi plateform interface, ?
> ( http://www.trolltech.com/products/qt/designer/sshots.html ;
> qt is used in kde: www.kde.org)

There have been several discussions in the past about what GUI library
to use and how to interface to that library. But we never got to a
decision what to do about it. Lack of time and resources has put it
all to a very low priority here at the commercial side of Erlang.

> 4) how complex would it be it to hack gs to use qt instead of
> whaever is used ?

Lots of work I think. We tried to make the Erlang GS frontend generic
but the Tk way of handling graphics shows up here and there. I haven't
looked at Qt but I suspect it works very different than Tk.  Even at
the basic level different GUI libraries tend to differ, some create
the container first and then create elements to fill them with, others
create the elements first and then the container.

> 5) whoever experimented binding erlang to graphics, where a re
> coming the inefficiencies, and difficulties ?

One problem is where to put your time and money ;-) When I worked at
SICS we built the SICStus Prolog GUI interface around the InterViews
GUI library, then InterViews died. When GS was created Tk looked like
the way to go. Will it be Qt or GTK+ or both? If GS was truely generic
we could switch from one backend to another over time.

We also want to support the Windows platform. Qt and soon also GTK+
seem to support it. But do they support the "native look and feel" on
Windows, i.e. does the GUI components look and work like the Windows
user expects without Erlang programmerwriting code for it? We have
that problem with GS, it is based on an old Tk version that doesn't
support Windows native look and feel.

Another problem is on what level to interface the GUI library. In GS
we built our own interface to fit Erlang but this hides lots of
features that Tk has but GS hasn't. The Erlang GTK application
(unsupported direct interface to Tk that are part of the OpenSource
release) approach has the drawback that it doesn't include Tcl. High
level widgets written in Tcl can't be used (I'm not 100% that this is
true).

You also have to choose if you want to link the Erlang executable
together with the GUI library. The GUI library code may contain bugs
that takes down the Erlang node. This was the reason why GS is an
external process. The drawback is the performance lost having to
communicate with the other OS process.

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.

A new backend for GS using Qt would of cause be great. If I was the
one to do it I think I would try to write some sort of frontend
specification and write a generator program to generate most of the
backend code, both on the Erlang side and the C++ side. This way new
object could easily be added and changes in the communication model
just require a change in the generator.

kent