Re: Second alpha release of scwm

[Maciej Stachowiak <mstachow@mit.edu>]

First of all, here is the announcement I made that these were
responses to, just so people on the fvwm list don't end up massively
confused:

I wrote:
> The second alpha release of scwm (pronounced "squim", to whyme with
> "swim"), the Scheme-Configurable Window Manager is now avaialble at
> 
> http://web.mit.edu/mstachow/www/scwm.html
>
> scwm is currently a hack of fvwm2 that has the configuration
> language replaced with Guile Scheme. Eventually it will evolve into
> something that is both much leaner and much more configurable.
>
> No one sent me any feedback on the last alpha release. I'd really
> appreciate it if some people would try it and send me their
> comments, suggested changes, etc.

Now, my response to recent comments here:

Bruce Stephens <B.Stephens@isode.com> wrote:
>dan@telent.net said:
> > 1) sufficiently general window decoration primitives that I can have 
> > it look like (c)twm with SqueezeTitlebars set.  Hey, I like them ... 
> > (Incidentally, gwm couldn't do this, as far as I could figure out) 
> >
> fvwm2 can't yet do this.  I'd guess the development for this ought
> to go in core fvwm as well.  On a more general point, how much does
> fvwm2 have to be hacked to produce scwm?  Is there something simple
> that could be done to fvwm to help it to be modified in this way?
> It strikes me that perl users might want to have fvwm configured
> using perl, for example.

Converting the builtins themselves was relatively simple for most
cases. Some trickiness arose from the fact that all fvwm builtins get
a good deal of implicit contextual information (what window, if any
they are operating on, etc) and this was tricky to convert. However,
in doing the conversion, I have often made my Scheme procedures much
simpler than the fvwm commands they emulate, because the extra
features of the fvwm commands could be done by using normal scheme
functionality. As an example, instead of making move-pointer-to (my
equivalent of move-cursor) be able to move the pointer either
absolutely or relatively, I added a procedure that gets the current
pointer position and wrote the relative move version in scheme using
those. As another example, I wrote the Next, Prev and WindowList
command equivalents entirely in scheme based on very simple
primitives. So while a conversion _could_ be done almost mechanically,
it is a big win to give it deeper thought.

>
>dan@telent.net said:
> > 2) ability to execute bits of scheme after the wm starts, so 
> > customisation isn't the endless edit-save-restart cycle that it seems 
> > to be on almost any other window manager.  
>
> fvwm can already do this, using its module interface.  Perhaps that's 
> something that's nontrivial to convert to scheme, or perhaps it just hasn't 
> been a priority for the author.  There are a couple of modules which allow 
> communication with fvwm and execution of almost arbitrary commands (I think 
> there are some which really do have to be done at wm startup, but perhaps 
> I'm wrong and all these have now been removed).
>
> Come to think of it, couldn't the whole exercise be done by writing a fvwm2 
> module in guile which converted guile statements into fvwm2 and sent them?  
> (You'd need a minimal .fvwm2rc which started the module.)  Parts of this 
> already exist for other languages.
>

The whole exercise _could_ be done that way. In fact, I think there
are already FvwmPerl and FvwmPython modules done this way. I decided
to do it by converting the binary itself because it will eventually
save a lot of memory to be able to get rid of the fvwm parsing and
control-flow machinery, as well as all the weird features of many fvwm
commands that are there because the fvwmrc language lacks things like
conditionals and arithmetic. In fact, I think I might be able to use
less memory than fvwm2 eventually, if you don't count the guile shared
library.

 - Maciej Stachowiak