Jay Kuri <jaykuri_at_oneway.com> writes:
> > 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
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
bradym_at_cs.arizona.edu
--
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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Aug 25 1997 - 18:06:35 BST