[Caml-list] Skinnable windowing system in OCaml

[Caml-list] Skinnable windowing system in OCaml

[Walter B. Rader]

I'm developing a windowing system (a la X Windows) in OCaml using SDL
(Simple DirectMedia Library) which is a cross-playform graphics library
written in C.

I want the end user to be able to configure the "look-and-feel" of the
windowing system at runtime, and I'm not sure the best way to go about
doing this.  Currently, the window manager calls upon a class called
"decorator" that performs the window decorations (title bar, frame, etc.)
The decorator class could be sub-classed (or perhasp redefined?) to
change the behavior.

Any thoughts on the "best way"?  Is it possible to compile several
different modules that contain a decorator class (with, say, a Windows 95
theme, a MacOS theme, etc.) and dynamically load one?  Would loading one
redefine the "decorator" class that was defined prior to the loading?
If I understand correctly, the dynamic loading works with byte-code
compiled modules?  If the main program were compiled to native code, would
they work together seamlessly?

Are there any resources (books, papers, how-to's about "this kind of
thing" (e.g. loading modules at run-time to redefine default behavior)?  I
know of plenty books about designing OSs but haven't found any about
writing windowing systems.

Any suggestions about anything even remotely related to the above
subject/questions would be more than welcome!

Thanks,

Walter Rader

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Skinnable windowing system in OCaml

[John Prevost]

On Wed, Jan 09, 2002 at 05:41:21PM -0800, Walter B. Rader wrote:

>I want the end user to be able to configure the "look-and-feel" of the
>windowing system at runtime, and I'm not sure the best way to go about
>doing this.  Currently, the window manager calls upon a class called
>"decorator" that performs the window decorations (title bar, frame, etc.)
>The decorator class could be sub-classed (or perhasp redefined?) to
>change the behavior.

I've thought about this in the past.  Here's the way you want to
approach things for dynamic loading, with or without objects.  (You
could also use a record of functions for this, most likely.)

When a module loads, everything in it executes to define various
functions and also to have side effects.  It is impossible, however,
to try to refer to symbols from the namespace of a module you're
loading.  If you refer to the symbol, the module must already have
been loaded before your referring module is loaded (static scope.)

What you should do is have your main code for the engine provide
a well known set of hashtables or lists or the like which are
mutable and can be updated by modules that are loaded later, possibly
by calling functions in your API.  Whenever a new "skin" loads, it
adds itself to the registry of skins in this manner.  Then the
engine may access the new code by looking up the functions/objects/etc.
from the registry.

This does not provide a way to "unload" old modules.  It does,
however, allow you to load more modules as time goes on, or load
one module at startup, or whatever you'd like.

John.
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr