Subject: Re: FVWM: Re: FVWM Internal Modules ? (FIM?)

From: Jay Kuri <[email-masked]>
Date: Mon, 25 Aug 1997 16:43:20 -0500 (CDT)

> This is approximately what I was suggesting.  It sounds like the modules
> that you want to use are dynamically loaded, while I was just suggesting
> a well defined interface so that you could add a block of code at compile
> time.
    Actually, you and I seem to be talking about the same thing =).  Not
dynamically loaded, but able to be compiled in when building fvwm... Maybe
distributed as 'contrib' code.

> Major code overhaul.  The current behavior of Fvwm is implicitly hardcoded
> in almost all parts of the code.
   =/  Hmm.  I'm still willing to look into it/work on it...

NOTE: for rest of email, module=compiled-in optional code, NOT traditional
FVWM Modules

  Hows this for a possible configuration:

	Compile in contrib window-decor module.
	If module specific style used on TitleStyle, etc,
	call the module-decor code for window, otherwise do the 'normal'
	fvwm decor.

In otherwords, make these modules as extensions... as you can have both
'normal' and 'extended' modules compiled at once.

  Is there enough demand/support for making such modifications to the
code?  If this is pursued, how likely is it that it will be rolled back
into the fvwm distribution?  Are there people aside from me who would be
interested in working on this?  

Jay Kuri

---
Everyone can be taught to sculpt:  Michelangelo would have had to be 
taught how not to.  So it is with the great programmers.

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Brady Montz <[email-masked]>
Date: 25 Aug 1997 16:06:15 -0700

> interested in working on this?  

I've been interested in working on this for some time, since it is a very
stripped down version of a problem I'm working on for my thesis. I think that
to do it right would require major rewriting of fvwm. I posted something
awhile back on this, but basically I can see using modules for:

1. appearance
2. configuration (both reading in config info and doing run-time
   configuration)
3. policy (how focus gets shifted from window to window, functions which
   manipulate the fvwm window list like Next, Prev, etc)
4. possibly even interfacing with the underlying window system. It would be
   cool if it would be possible to run fvwm on the BeOS or Rhapsody or
   windows.

The basic mechanism that I was thinking of is:

1. As far as the fvwm kernel is concerned, there is only one type of module -
   those writeen in C directly linked into fvwm. 

2. modules written in an interpreted language (please, if this is to be lets
   standardize on only 1 language), would be run by making the interpreter
   into a module, and it handles running the interpreted code. So if we picked 
   python, then we write the necessary C functions to make the python
   interpreter look to fvwm like a module, and then we have python code which
   mediates between fvwm and the python modules.

3. we could have a module which is just a stub, and acts as a proxy via RPC
   for a module running as an external program. Using this stub module, we
   could connect an external program to fvwm and as far as fvwm is concered,
   it's exactly like a directly linked in piece of code. We should have a
   module library so that modules could operate in either mode, just by
   setting the right compile time flags. So I could have my titlebar drawing
   module loaded into the fvwm executable via dlopen(), or have it compiled as
   a seperate executable and it talks to the stub proxy module via RPC. This
   would be useful for both debugging, and having modules which outlive fvwm.

4. Finally, the current fvwm modules would talk to a simple linked in module
   which simply spits out all those messages to the external modules.

The main problem is figuring out which data and functions the linked in
modules are allowed to access, how control gets transferred to them from fvwm,
and sychronization. And if you have multiple types of modules linked in doing
the same thing (like two different look-and-feel modules), how does fvwm
demultiplex between them. Basically, you've got a mini OS (but that doesn't
mean it has to be slow. Here at the U of Arizona we like writing small fast
OS's). 

The hardest part is figuring out how exactly fvwm transfers control to module
code. While the fvwm code is nicely organized, it's not at all modular. The
method we use in the Scout OS to handle this is by having each module export a
structure with a bunch of function pointers. There are various types of
interfaces depending on the type of the module. So a module which handles
window decorations has to export one set of functions (probably many), and a
module which reads in the config file needs to export another (probably just
one: readConfig()). This has the two necessary properities that it: (a)
decouples module A from module B, so that module B can be replaced quickly
with something else, and arbitrary code can be inserted between the two
modules cleanly; and (b) it allows the program to manipulate the functions in
groups.

-- 
 Brady Montz
 [email-masked]