> 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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Aug 25 1997 - 16:50:30 BST