about graphics and GUI

Luc Taesch ltaesch@REDACTED
Sat Sep 16 21:37:16 CEST 2000


Kent Boortz wrote:

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

thks for ure detailled answer.

>
>
> > 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 ;-)

im runing on a p3 450 128 mo, and the 2startng takes 0.5 to 1-2 s.
hm ? is it some engine start ?

>
>
> > 2) is it possible to integrate erlang with c++, or c only ?
>
> How do you want to integrate Erlang with C++?

i dont know yet, but i thought i read somewhere u cannot.


> 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++.
>
>

> > 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)
>



>
>
> 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,

Qt does . look at the previous link. this is one of the strength (on top
of being nice to look at)


> 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).

thats the common issue with leveraging the interface.

>
>
> 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.

good point. havent thought of, but in eiffel we had this problem too.


>
>
> 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. ?

>

>
>
> 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.

interesting. do u know of any research in that area ?

another point, has anybody looked at the haskell community work ? are
there any  academics  work around that ?

>
>
> kent

--
First, they ignore you.
Then, they laugh at you.
Then, they fight you.
Then, you win.

--- Gandhi.

Working code is what matter, not your market capitalization.
--Kurt granroth


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20000916/e209658c/attachment.htm>


More information about the erlang-questions mailing list