<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Kent Boortz wrote:
<blockquote TYPE=CITE>I will try to answer, maybe someone else can fill
in.</blockquote>
thks for ure detailled answer.
<blockquote TYPE=CITE>
<p>> 1) when using toolbars, say table monitor, we can see the "graphics
<br>> initialising" which take a while. is the delay it due to the
<br>> erlang, or some lib ? is it using tk, or gs ? where are the
<br>> ineffcencies coming from ? (no flamewar intended )
<p>I can't say what is taking the time but the GS library is very
<br>inefficient. Lots of strings are sent from the Erlang node to an
<br>external OS process.
<p>But I can't repeat the problem, my home machine is so fast I don't
<br>even see a the dialog you talk about ;-)</blockquote>
im runing on a p3 450 128 mo, and the 2startng takes 0.5 to 1-2 s.
<br>hm ? is it some engine start ?
<blockquote TYPE=CITE>
<p>> 2) is it possible to integrate erlang with c++, or c only ?
<p>How do you want to integrate Erlang with C++?</blockquote>
i dont know yet, but i thought i read somewhere u cannot.
<br>
<blockquote TYPE=CITE>CORBA and other "high
<br>level" integration is no problem. ERL_INTERFACE is written for C but
<br>has the usual
<p> #ifdef __cplusplus
<br> extern "C" {
<br> #endif
<p>to make the functions callable from C++. Even the header file for
<br>writing Erlang linked in drivers is adjusted to work for C++.
<br>
<br> </blockquote>
<blockquote TYPE=CITE>> 3) Qt libs is now under GPL. would it be interesting
to use it as a
<br>> multi plateform interface, ?
<br>> ( <a href="http://www.trolltech.com/products/qt/designer/sshots.html">http://www.trolltech.com/products/qt/designer/sshots.html</a>
;
<br>> qt is used in kde: www.kde.org)
<br> </blockquote>
<br>
<blockquote TYPE=CITE>
<p>We also want to support the Windows platform. Qt and soon also GTK+
<br>seem to support it. But do they support the "native look and feel"
on
<br>Windows,</blockquote>
<p><br>Qt does . look at the previous link. this is one of the strength
(on top of being nice to look at)
<br>
<blockquote TYPE=CITE>Another problem is on what level to interface the
GUI library. In GS
<br>we built our own interface to fit Erlang but this hides lots of
<br>features that Tk has but GS hasn't. The Erlang GTK application
<br>(unsupported direct interface to Tk that are part of the OpenSource
<br>release) approach has the drawback that it doesn't include Tcl. High
<br>level widgets written in Tcl can't be used (I'm not 100% that this
is
<br>true).</blockquote>
thats the common issue with leveraging the interface.
<blockquote TYPE=CITE>
<p>You also have to choose if you want to link the Erlang executable
<br>together with the GUI library. The GUI library code may contain bugs
<br>that takes down the Erlang node. This was the reason why GS is an
<br>external process. The drawback is the performance lost having to
<br>communicate with the other OS process.</blockquote>
good point. havent thought of, but in eiffel we had this problem too.
<br>
<blockquote TYPE=CITE>
<p>A drawback with using GS as a frontend to a Qt backend is that we
<br>can't design our GUI with the graphical GUI builders available for
<br>Qt. Maybe the idea of having an interface, like GS, to a GUI library
<br>in Erlang isn't a good idea at all. You can write the GUI in C++ and
<br>communicate with Erlang at the application level instead. This of
<br>cause require that you define your own communication between the
<br>Erlang application and the corresponding C++ program and the fast
<br>start up development time using GS is lost but it is something to
<br>consider.</blockquote>
the standard would be the protocol then, rather than the interface. ?
<blockquote TYPE=CITE> </blockquote>
<blockquote TYPE=CITE>
<p>A new backend for GS using Qt would of cause be great. If I was the
<br>one to do it I think I would try to write some sort of frontend
<br>specification and write a generator program to generate most of the
<br>backend code, both on the Erlang side and the C++ side. This way new
<br>object could easily be added and changes in the communication model
<br>just require a change in the generator.</blockquote>
interesting. do u know of any research in that area ?
<p>another point, has anybody looked at the haskell community work ? are
there any academics work around that ?
<blockquote TYPE=CITE>
<p>kent</blockquote>
<pre>--
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</pre>
</html>