surrel@[EMAIL PROTECTED]
(Yves Surrel) wrote in message
news:<4fe1a34c.0408180032.1a130c81@[EMAIL PROTECTED]
>...
> Hello
>
Thank you for reacting.
Good ideas about OpenGL. I spent some time browsing about. In fact,
OpenGL by itself does not handles user events (keyboard and mouse).
This is done by a wrapping software layer (GL Utility or GLUT, or
FreeGLUT that seems to be more maintained). The openGL demo at
<http://www2.megawolf.com/~ward/updates/OpenGLdemo.sit>
is veeeeery
nice! However, GLUT implements only very limited features, e.g. only
popup menus.
It would be very useful to have a common Forth interface to OpenGL
(W32Forth and PowerMops and others).
However, I still assert that the windowing stuff should be separated
from forth, even in a different language, OO-forth dealing only with
non-display-related issues (at least low-level ones). Think to forth
in this framework as a resource accessed by the user interface.
I am wondering whether a client-server architecture could be
interesting. A Forth server could be nice. What could be the best
communication between clients and the server:
-shared library could be a solution (I have still some problems, see
the thread "Shared libraries" in this forum...);
-OS messaging system (OS dependent..., what about speed?)
-using sockets (same question...)
-other?
The built-in interpreter and compiler of Forth makes the server
concept very attractive. The clients have only to communicate with
strings (think of the communication to a database server with SQL, for
example), with the enormous advantage of the extensible wordset. At
configuration time, the client sends the string ": MyProc < known
words > ;" and at execution time it sends "MyProc". Very practival and
efficient. All the power of and object-oriented engine available to
any client.
But please try to think about separation of user interface and the
Forth core.
Cheers
Yves
|
