scwm-devs — For developer discussions regarding the Scheme Constraints Window Manager

[Scwm-devs] done testing winops-menu.scm

[Scott L. <sl...@cs...>]

I'm done testing winops-menu.scm.

Summary:

One fix to deiconify in small ops.

In 'menu-window-ops' "Change theme" and "Swtich to..." are still
broken but this is due to errors in other files that haven't been
tested yet.

Changelog:

	* winops-menu.scm: Fixed Unminimize option in
	'make-small-window-ops-menu' so that it does the right thing.

:-)

- Scott

[Scwm-devs] done testing shutdown-opts.scm

[Scott L. <sl...@cs...>]

I'm done testing shutdown-opts.scm

This completes the "window control"/"virtual desks/viewports"
section.

Summary:
works fine
minor addition to doc

changelog:

	* shutdown-opts.scm: Added mention of the default value to
	'shutdown-options'.

:-)

- Scott

[Scwm-devs] fvwm pager support broken for newest fvwm

[Scott L. <sl...@cs...>]

Bad news.

The newest version of the fvwm pager (2.4.x) breaks our compatibility
layer.  It prevents it from displaying windows.  The old version
from 2.2.x works fine.

Probably is just a minor change but need to determine what the change
is a find out if there is a way to autodetect which version of the
pager is being used.

- Scott

[Scwm-devs] done testing virtual.scm

[Scott L. <sl...@cs...>]

I'm done testing virtual.scm.

Summary:
minor doc improvements
added FIXMEs for two things not broken but either strange or dangerous
deprecated 2 overly specific functions (but just renamed one of them)

Changelog:

	* virtual.scm: Various doc fixes/improvements.
	Added FIXMEs about changing names to be consistent.
	Added FIXME about strange location choice by move-to-viewport.
	Added FIXME about dubious assumptions (that currently hold) in
	  'deiconify-to-current-viewport'.
	Deprecated 'switch-to-first-desk' and 'switch-to-second-desk'
	  since they are way to specific and have names longer than the
	  function calls they replace.
	Added 'switch-to-home-desk' as reasonably special enough to have
	  its own function.  This was names 'switch-to-first-desk'.

Enjoy.

- Scott

[Scwm-devs] done testing edge-ops.scm

[Scott L. <sl...@cs...>]

I'm done testing edge-ops.scm.

Summary:

Entire file broken and redundant with a working C implementation.

Changelog:

	* edge-ops.scm: Marked entire file as broken.  This code is
	redundant with the C code anyway and the C code actually works.
	I have trouble believing this code ever worked.

	Fixed a bad variable reference to a variable that does not exist.
	
	Moved add-hook! parts into new public function 'edge-ops-add-hooks'
	just in case someone has found a way to use this file.  This should
	protect people from screwing up the edge scrolling stuff with this
	broken implementation.  Added 'edge-ops-remove-hooks' as a safety
	for anyone silly enough to run 'edge-ops-add-hooks'.  Both functions
	marked deprecated.

Enjoy.

- Scott

[Scwm-devs] Re: edge-ops.scm vs. C code

[Greg B. <ba...@cs...>]

Scott Lenser <sl...@cs...> writes:

>   What's the relationship between edge-ops.scm and the
> C code for scrolling around the viewport over the
> virtual desktop?  They seem to be redundant.  Both the
> scheme code and the C code are ancient and from around
> the same time period.

Sorry, I don't remember offhand... if they are redundant, I'd pull the C
code out and simplify the core.

Thanks,
Greg

[Scwm-devs] edge-ops.scm vs. C code

[Scott L. <sl...@cs...>]

Greg,

  What's the relationship between edge-ops.scm and the
C code for scrolling around the viewport over the
virtual desktop?  They seem to be redundant.  Both the
scheme code and the C code are ancient and from around
the same time period.

- Scott

[Scwm-devs] bug fix in window-configuration.scm

[Scott L. <sl...@cs...>]

Noticed a bug in window-configuration.scm that only pops
up when simultaneously moving and resizing a window that
has a gravity other than 'northwest.

The values for 'set-end-x?' and 'set-end-y?' were being set
incorrectly.

Changelog:

	* window-configuration.scm: Fixed bug in generation of xforms
	for 'animate-windows' which made 'apply-window-configurations'
	claim that we weren't moving the window.  This caused the
	final position to be wrong if the window had any gravity except
	northwest.

	Add doc string to 'apply-window-configurations'.

- Scott

[Scwm-devs] done testing snap.scm and window control/position-size group

[Scott L. <sl...@cs...>]

I'm done testing snap.scm.  This completes the
"window control"/"position/size" group of scheme files.

Changed behavior of snap routines to be what I expected.
Realized a potential advantage of the old way and so made
a public variable which controls which behavior you get.
The default is the new behavior.  The difference is whether
snap will line up the left sides of two windows if they end
up close after the interactive move.  The new behavior lines
them up, the old doesn't.  Old snap will only line up the
left of one window with the right of another.  Same deal for
top/bottom.

Here's the changelog:

	* snap.scm: Changed name of 'snap-reset' to 'snap-disable'.
	Made 'snap-reset' deprecated.
	Added a few comments.
	Changed name of internal function imeh to imfh to match the
	name of the hook it gets installed into.
	
	Enhanced so that windows will also snap to the inside of each
	other (e.g. the left edge of a window will snap to the left
	edge of another window).  Added public variable
	'snap-matches-inside-edges' to control whether to use the new
	behavior or the old.  Default is #t which uses the new behavior.

Enjoy.

The stuff left to test in the "window control" group is:

winops-menu, groups
constraints - might postpone checking this
hints (kde, gnome) - will probably punt on this for now since I
  don't run either kde or gnome
virtual desk/viewports

Woohoo, over half done with this major section.

- Scott

[Scwm-devs] done testing tile.scm

[Scott L. <sl...@cs...>]

Few minor updates but mostly fine.

Changelog:

	* tile.scm: Added missing :use-module for flash-window.
	Fixed #:raise restack-only for 'tile-windows'.
	Changed default direction for 'tile-windows-interactively' to
	  horizontal to match 'tile-windows' and the most common
	  direction for tiling things.
	Fixed ordering of selection from 'selected-windows-list'.
	Changed to 'push-undo-global' from broken 'innsert-undo-global'.

Enjoy.

- Scott

[Scwm-devs] done testing shove-window.scm

[Scott L. <sl...@cs...>]

This one was easy.  It worked fine.  I added a comment anyway.
We don't have any way to document a public variable, do we?
We should make a way.

Changelog:

	* shove-window.scm: Added a comment to 'menu-window-shove'.

This scheme files pretty cool.  I might just have to change my
configuration to take advantage of this one :-).

- Scott

[Scwm-devs] done testing placement.scm

[Scott L. <sl...@cs...>]

Executive summary:

several doc improvements
one bug squashed
added several FIXMEs for the incredibly redundant code

Changelog:

	* placement.scm: Doc fix to 'interactive-placement'.
	Doc addition to 'near-window-placement'.
	Doc clarification for 'make-keep-winclass-centered'.
	Added several FIXMEs about stuff that should be cleaned up eventually.
	Fixed bug in 're-place-window'.

Enjoy.

- Scott

[Scwm-devs] done testing cascade.scm

[Scott L. <sl...@cs...>]

I'm done testing cascade.scm.

Needed a little polish and one bug fix.

Here's the changelog:

	* cascade.scm: Added a couple of missing modules, flash-window and flux.
	Made 'meta-apply' plublic and gave it a doc string.
	Clarified 'cascade-windows' doc.
	Made #:raise #t work for 'cascade-windows'.
	Made #:reverse #t the default for 'cascade' since 'cascade-windows'
	  processes from bottom to top but most of our lists are top to bottom.
	Made 'cascade' listify atoms passed in #:only and #:except to be more
	  consistent with the style stuff.
	Made selections get processed in selection order, so the first selected
	  window is put on the bottom.
	Updated to use 'push-undo-global' since 'insert-undo-global' is both
	  broken and deprecated.

	* flux.scm: Changed 'select-window-group' to return the list of windows
	in the order selected.

Enjoy.

- Scott

[Scwm-devs] done testing auto-unobscure.scm

[Scott L. <sl...@cs...>]

Done testing auto-unobscure.scm.
Just needed some updates to adjust for bit rot and a couple
doc strings.  Works really nicely with clever-place-window.

Changelog follows:

	* auto-unobscure.scm: Updated from object-property/set-object-property!
	to window-property/set-window-property!.  Updated for new arguments to
	window-fully-obscured-hook.  Added doc strings for 
	enable/disable-auto-unobscure.

Enjoy.

- Scott

[Scwm-devs] done testing auto-shrink.scm

[Scott L. <sl...@cs...>]

This one was pretty good.  Only bugs were a missing :use-module
line and using a default value instead of the passed parameter
to one function.

Also added a couple of missing doc strings.

Here's the changelog:

	* auto-shrink.scm: Made 'shrink-inactive-windows' use the delay-seconds
	parameter it is passed.  Added missing :use-module line for
	(app scwm time-convert).

	Added doc strings to public functions missing them.

Enjoy.

- Scott

[Scwm-devs] finished testing undo.scm

[Scott L. <sl...@cs...>]

Finished testing undo.scm.

Executive summary:

Fixed undo/redo bug.
Improved the docs a bunch.
Deprecated 2 functions that shouldn't have been public.
Deprecated 2 functions that were broken and had strange semantics.
  Added doc noting this fact and what the net result of running it
  now is (same as another function).

Here's the change log:

	* undo.scm: Documented public variables.
	Updated and greatly improved documentation.
	Deprecated 'decrement-undo-index', 'increment-undo-index',
	'insert-undo-global', and 'insert-undo-state'.  The first 2
	should be private and the last 2 were broken and had bizarre
	semantics to begin with so I decided to deprecate instead of
	fix.

	Fixed bug in undo/redo that would result in having to do 2
	undos/redos in a row to reverse the effect of the last redo/undo.

	Implemented paying attention to undo-max-entries so that we don't
	just keep growing memory in the comon usage case.  Added function
	'truncate-undo-list' in the process to constrain the undo-list to
	be no larger than a given number.  Exported as public since may be
	useful to users.

Enjoy.

- Scott

[Scwm-devs] Re: done testing window-configuration.scm

[Greg B. <ba...@cs...>]

This is great!  It's amazing how many bugs you can get when no one is
thoroughly and methodically testing!  This is perhaps a testament to the
value of classical testing (over the free-software-world's organic
testing from end-user early adopters).  (But it could be lots of other
things, too!)

Thanks,
Greg


Scott Lenser <sl...@cs...> writes:

> I'm _finally_ done testing window-configuration.scm.
> 
> Ugh, what a load of bugs (mostly not in the code I was testing,
> which was just woefully incomplete).
> 
> I put the bugs on the bug tracking thingy on sourceforge
> if you want details.
> 
> Basically, saving window configuration now works for saving
> the position/size/stickiness of deiconified windows and saves
> the iconified status of iconified windows.
> 
> It is now pretty safe to do
> 
> (restore-global-connfiguration (global-configuration))
> 
> as it correctly acts like a no-op.
> 
> - Scott

[Scwm-devs] done testing window-configuration.scm

[Scott L. <sl...@cs...>]

I'm _finally_ done testing window-configuration.scm.

Ugh, what a load of bugs (mostly not in the code I was testing,
which was just woefully incomplete).

I put the bugs on the bug tracking thingy on sourceforge
if you want details.

Basically, saving window configuration now works for saving
the position/size/stickiness of deiconified windows and saves
the iconified status of iconified windows.

It is now pretty safe to do

(restore-global-connfiguration (global-configuration))

as it correctly acts like a no-op.

- Scott

[Scwm-devs] Re: bunch of bugs found in C stuff

[Greg B. <ba...@cs...>]

This is great!  Please keep up the awesome work -- you're likely right
to not mess with the C code in the immediate timeframe: just documenting
the known issues, fixes the doc problems, and working around or
disabling the most wrong stuff at the scheme level is a huge win.

Thanks,
Greg

[Scwm-devs] Re: how to move icon non-interactively

[Greg B. <ba...@cs...>]

Scott Lenser <sl...@cs...> writes:

> Greg,
> 
>   Is there any way to move an icon non-interactively?  I can't find any
> function that moves icons besides opaque-move and rubber-band-move both
> of which are interactive.

Possibly not; icon code in particular is ill-tested and potentially
incomplete since I never used icons (I prefer the pop-up window list for
switching tasks).

Thanks,
Greg

[Scwm-devs] bunch of bugs found in C stuff

[Scott L. <sl...@cs...>]

I'm still poking around with the window configuration stuff
(window-configuration.scm).  I keep finding problems with the
C code while debugging stuff as the interactions between sticky,
iconified, and shaded are pretty buggy.

Here are the bugs I've found:

-----------------------------------------------------

shade + iconify does not work properly

Display error bottom-left, bottom-right, and bottom
frame windows

Reproduction recipe is shade window, then iconify, then
deiconify.

Window will start out unshaded with bottom frame
windows not displayed and frame windows acting like
they do when shaded. Unshading window fixes the problem. 

------------------------------------------------------

(un)stick-icon wrong when win iconified 

Changing the stickiness of an icon while the icon is
visible results in unexpected results. Changes made
while the window is not iconified seem to be ok. The
position of the iconified window seems to not be
updated properly.

------------------------------------------------------

set-show-icon! closes windows

(set-show-icon! #f win) causes win to become invalid
[even if win is currently being displayed!!!] 

------------------------------------------------------

animate-windows on shaded window broken

using animate-windows to resize a window which is
shaded causes the window to have a frame which is too
small for the client window until it is resized

------------------------------------------------------

I've put all of these on the sourceforge bug tracker.

I'm almost done with window-configuration.scm (or at least
as much of it as I can given all the errors with the C
stuff).  I'm about to the point of basically characterizing
which combinations work and which don't.

I'm planning on leaving it in this half-broken state until
I can work on the C stuff which I don't really want to touch
until the next release.  I think it's a little better than
the last release but really needs some work on the C side
before it can be right.

Oh, I also found that the docs for list-stacking-order and
some other list-windows functions are incorrect in stating
that iconified windows are not listed.

- Scott

[Scwm-devs] how to move icon non-interactively

[Scott L. <sl...@cs...>]

Greg,

  Is there any way to move an icon non-interactively?  I can't find any
function that moves icons besides opaque-move and rubber-band-move both
of which are interactive.

- Scott

[Scwm-devs] Re: desired semantics question for window configuration

[Greg B. <ba...@cs...>]

Undo and window configuration definitely has some potentially surprising
effects---the best way to do undo would be to have each action record
its "undo action" rather than saving the entire window configuration
(though that's also useful for, e.g., bookmarking window configurations,
etc.).

In any case, what you write is perfectly reasonable.  I'd not change
from the list-based representation yet just because it may end up being
a bigger rewrite than you're interested in.  Regarding changes of names,
I'd change the names to things that are consistent and well-named and
make the existing names deprecated aliases to the better-named things.
I don't remember how bad the names are, but assuming they're really
awful and inconsistent, this would be a good thing to do---you may want
to run the names you propose by us just as a teddy-bear-test (you learn
as much from it just because you're explaining it to someone/something
else).

Thanks,
Greg


Scott Lenser <sl...@gs...> writes:

> I've got a question about what we should be doing with regards to
> storing/restoring window state as I'm currently investigating
> window-configuration.scm (which I moved to after determining that
> it is making undo.scm fail badly on sticky windows).  I decided
> undo was the next to get done since it should help me debug the
> stuff that's going to move windows all over the place.
> 
> The question is just what makes up the "configuration" of a window.
> In some sense the configuration of a window only makes limited sense
> without the context of where the display is currently located.  This
> is particularly the case with sticky windows.  It makes sense that
> sticky windows should have their configuration relative to the viewport
> (since they are stuck) rather than desktop (currently they are relative
> to the viewport which makes all my sticky windows go wandering off
> if I (restore-global-window-configuration (global-window-configuration))
> which should be a no-op).  But thinking more about this, this could have
> strange interaction with user functions which automatically change the
> sticky-ness of windows.  I don't think all strange interactions can
> be avoided without reference to the full state at the time the window
> configuration was recorded, yet it is very useful in most cases to
> be able to record most of the state of the window configuration.
> Therefore, we need to determine what we will record and then document
> that fact so if there are strange interactions they become the user's
> fault if they didn't follow what the docs say.
> 
> Also, the functions in window-configuration.scm seem to be poorly
> named so I'm considering making aliases and deprecating the old
> names.  I also think I'll make the basic data type a record since
> the list thing is sort of silly (unless there are objections).
> I'll make some sort of accessor like things for getting at the 
> interesting fields so we won't have to break backward compatibility
> if/when we start storing more state.  Changing from the list will break 
> code that relies on the specific format of window configuration.
> Er... on second thought, I'm not sure this is a good idea since all
> of the other functions return lists.  What do you think?  Maybe the
> format of this stuff is something to worry about post 1.0?
> 
> Here's what I propose.  Basic goal is to get basic position and
> state of windows right and forget the rest for now (decorations,
> blah, blah, blah...).  If I'm missing something needed to get
> the windows back to the correct position in some circumstances,
> YELL at me.  Pretty please?
> 
> ----------------------------------------
> 
> window configuration
> 
> frame-size
> sticky?
> iconified?
> shaded?
> if sticky?
>   position of window/icon relative to viewport
> else
>   position of window/icon relative to desktop
> (window/icon is icon if iconified and window otherwise)
> 
> -----------------------------------------
> 
> The graphical effect won't be quite as cool since I'll need to
> iconfiy/deiconify windows at a different time than the animation
> but I don't really care too much and I get the impression Greg
> doesn't either (although he's free to comment).
> 
> Proposed update order is:
> 
> iconify/deiconify as required
> shade/unshade as required
> stick/unstick as required
> animate windows as required to move/resize them to the right location
> 
> - Scott

[Scwm-devs] desired semantics question for window configuration

[Scott L. <sl...@gs...>]

I've got a question about what we should be doing with regards to
storing/restoring window state as I'm currently investigating
window-configuration.scm (which I moved to after determining that
it is making undo.scm fail badly on sticky windows).  I decided
undo was the next to get done since it should help me debug the
stuff that's going to move windows all over the place.

The question is just what makes up the "configuration" of a window.
In some sense the configuration of a window only makes limited sense
without the context of where the display is currently located.  This
is particularly the case with sticky windows.  It makes sense that
sticky windows should have their configuration relative to the viewport
(since they are stuck) rather than desktop (currently they are relative
to the viewport which makes all my sticky windows go wandering off
if I (restore-global-window-configuration (global-window-configuration))
which should be a no-op).  But thinking more about this, this could have
strange interaction with user functions which automatically change the
sticky-ness of windows.  I don't think all strange interactions can
be avoided without reference to the full state at the time the window
configuration was recorded, yet it is very useful in most cases to
be able to record most of the state of the window configuration.
Therefore, we need to determine what we will record and then document
that fact so if there are strange interactions they become the user's
fault if they didn't follow what the docs say.

Also, the functions in window-configuration.scm seem to be poorly
named so I'm considering making aliases and deprecating the old
names.  I also think I'll make the basic data type a record since
the list thing is sort of silly (unless there are objections).
I'll make some sort of accessor like things for getting at the 
interesting fields so we won't have to break backward compatibility
if/when we start storing more state.  Changing from the list will break 
code that relies on the specific format of window configuration.
Er... on second thought, I'm not sure this is a good idea since all
of the other functions return lists.  What do you think?  Maybe the
format of this stuff is something to worry about post 1.0?

Here's what I propose.  Basic goal is to get basic position and
state of windows right and forget the rest for now (decorations,
blah, blah, blah...).  If I'm missing something needed to get
the windows back to the correct position in some circumstances,
YELL at me.  Pretty please?

----------------------------------------

window configuration

frame-size
sticky?
iconified?
shaded?
if sticky?
  position of window/icon relative to viewport
else
  position of window/icon relative to desktop
(window/icon is icon if iconified and window otherwise)

-----------------------------------------

The graphical effect won't be quite as cool since I'll need to
iconfiy/deiconify windows at a different time than the animation
but I don't really care too much and I get the impression Greg
doesn't either (although he's free to comment).

Proposed update order is:

iconify/deiconify as required
shade/unshade as required
stick/unstick as required
animate windows as required to move/resize them to the right location

- Scott

Re: [Scwm-devs] Trouble Compiling CVS version

[Scott L. <sl...@gs...>]

> Scott,
> 
> Excuse me but I am pretty ignorant about a lot of UNIX programming but...
> 

No problem.  Everyone has to start somewhere.

> Here are a couple things I have found.
> 

Thank you.

> In modules/scwmgtk helper -I$(top_srcdir)/include should be added to the 
> include line.
> 
>  INCLUDES = -I$(SCWM_SRC_DIR)  -I/usr/X11R6/include 
> -I/usr/local/guile-1.4/include  -I/usr/local/include 
> -I/usr/local//include -I$(top_srcdir)/include
> 

This include should already be in the DEFS variable which gets passed
to the compile.  It probably should get moved to the INCLUDES var but
this is auto* magic which I don't know much about and am therefore
loath to touch.

> In modules make-devtest the #!/usr/bin/zsh line has usr misspelled.
> 

This is the standard spelling for the path to this executable.  It needs
to be spelled this way for the executable to be found.  It is actually
an abbreviation similar to /var and /etc.

> I have guile-1.4 in /usr/local/guile-1.4.  Even when I set the $PATH and 
> $LD_LIBRARY_PATH to
> point to the right directories  gawk cannot find "guile-func-name-check" 
> for some reason.
> I ended up putting links to all the guile programs in /usr/bin/ so that 
> scwm could compile.
>

It looks like the Makefile currently insists that guile-doc-snarf be in
your path.  I'll add fixing this to my TODO list.

gawk not finding this seems to be because the guile-doc-snarf that comes
with guile 1.4 insists on guile-func-name-check being in your current
directory.  This is pretty broken, I hadn't realized this problem
existed.  This won't effect the build as this part simply checks to
make sure that things are ok.  I'll look into workarounds.  For the
moment, workaround is ignore error messages about not finding
guile-func-name-check.
 
> The last thing is, no matter what I do I cannot get "anchor.xpm" to be 
> found, even after adding
> the correct path to .scwmrc.   It's almost as if the image-load-path 
> variable is unitialized at the
> point that xpm is needed.
>

Send me your .scwmrc and an 'ls -l' listing of the full path to the file
and I will investigate.
 
> I am attempting to run scwm out of /drives/work/src/scwm-cvs/scwm.  I 
> have guile in
> /usr/local/guile-1.4 and the gnome  binaries and setup is in /usr/local/
> 
> I still have not found out why session-manager.c is not being built but 
> your suggestion
> allowed me to build it manually.
> 

Please send me a tarball of the complete build directory for scwm
so I can figure out what is going wrong with the session-manager
build.  Also send me the command line you used to configure.  Don't
worry about size.  The mail servers here can handle it.

> Attached are some files that may help you make sense of all this.
> 
> Thanks!
> 

Well, you already found to bugs for me so I think we're even.  Your
welcome anyway though.

> I would be especially grateful if you could give some tips on how to get 
> rid of some of the
> errors I'm getting in .SCWM-errors.
> 

see below.

> Lastly, I am a newbie to scheme, but I got a book and am trying to learn.
> 

There are some supposedly some good resources on the web like
schemers.org.  I haven't tried them myself since I had to learn
for a class and we used the MIT Scheme reference manual.

- Scott

From your error file (a copy of the .scwmrc would help diagnose the errors):

>Merging in /home/heitkamp/.Xresources
>scwmmessages:  unable to open font "-*-lucidatypewriter-medium-r-*-*-12-*-*-*-*-*-*-5", trying "fixed"....
>xterm:  unable to open font "-*-lucidatypewriter-medium-r-*-*-12-*-*-*-*-*-*-5", trying "fixed"....

Couldn't find this font, is it installed?

>Exec-ing wm as /drives/work/src/scwm-cvs/scwm/src/scwm
>;;; loading /drives/work/src/scwm-cvs/scwm/app/scwm/gnome-hints.scm
>[...]
>;;; loading /drives/work/src/scwm-cvs/scwm/app/scwm/modifier-key-bindings.scm
>[Scwm][make-image]: <<WARNING>> Image file was not found: `anchor.xpm'
>[Scwm][make-image]: <<WARNING>> Image file was not found: `anchor-cursor.xpm'

Not sure what is going on here.  Your .scwmrc file and an ls -l listing
of the location of these files would be helpful in diagnosing the problem.

>;;; loading /drives/work/src/scwm-cvs/scwm/app/scwm/style.scm
>;;; loading /drives/work/src/scwm-cvs/scwm/app/scwm/placement.scm
>;;; loading /drives/work/src/scwm-cvs/scwm/app/scwm/focus-stack.scm
>;;; loading /drives/work/src/scwm-cvs/scwm/app/scwm/window-locations.scm
>ERROR: Unbound variable: scwm-set-master-solver!

This is being caused by a build problem.  The scwm support for cassowary
is not getting built in.  It looks from your configure log like scwm
was not configured with cassowary support although I can't be sure.
I you did configure with cassowary support the Makefile.* files might
help me diagnose the problem.

>ERROR: Unbound variable: enable-gnome-hints
>

Don't know what's going on here.  This should have been defined by
./app/scwm/gnome-hints.scm which is getting loaded above.

>;;; loading /drives/work/src/scwm-cvs/scwm/app/scwm/lambda-startup-logo.scm
>[...]
>;;; loading /drives/work/src/scwm-cvs/scwm/app/scwm/gtk.scm
>
>;;; WARNING (no code for module (gtk gtk))
>
>;;; WARNING (no code for module (gtk gdk))
>

This means it couldn't find the Guile module for gtk/gdk.  Make
sure you have guile-gtk installed.  On debian, this is the following
two packages or equivalent.

ii  libguilegtk-dev 0.20-8.1 Dev libraries for Guile-Gtk scheme interpreter
ii  libguilegtk0    0.20-8.1 Libraries for Guile-Gtk scheme interpreter

>0* (enable-gnome-hints)
>
>/home/heitkamp/.scwmrc:139:1: In expression (enable-gnome-hints):

Basically, same error as above.  No clue.

>/home/heitkamp/.scwmrc:139:1: Unbound variable: gdk-get-leader-window-id

propagation of the guile-gtk problem

>;;; loading /drives/work/src/scwm-cvs/scwm/app/scwm/synth-events.scm
>[...]
>ERROR: Unbound variable: gnome-install-window-styles
>

Your gnome support is screwed up some how.

>ERROR: Unbound variable: at-point-placement
>
>ERROR: Unbound variable: at-point-placement
>

This should have defined by placement.scm which got loaded above.

>[Scwm][bind-key]: <<WARNING>> Unbound modifier H-
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-r'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-slash'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-M-slash'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-s'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-h'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-w'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-A-M-C-d'
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-2
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-3
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-1
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-S-s'
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-S-1
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-A-1
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-S-2
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-M-3
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-z'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-p'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-e'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-S-e'
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-C-A-1
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-C-A-3
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-4
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-C-4
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-M-4
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-5
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-C-5
>[Scwm][bind-mouse]: <<WARNING>> Ignoring mouse bind/unbind request for H-M-5
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-M-g'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-g'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-f'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-c'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-x'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-t'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-period'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-S-period'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-M-period'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-M-S-period'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-d'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-q'
>[Scwm][bind-key]: <<WARNING>> Ignoring key binding `H-M-x'

You are trying to bind things to the hyper modifier bit but you haven't
bound the hyper modifier bit to any key.  You need to either use xmodmap
to bind something to the hyper modifier bit or choose different bindings
for these functions.

>Audio File Library: could not open file '/drives/work/src/scwm-cvs/scwm/Media/scwm-startup.wav' [error 3]

Does this file exist?

>[...]
>ERROR: Unbound variable: snap-initialize
>

You need to include this module in your .scwmrc file.  You
can do this with

(use-scwm-modules snap-constraints)

>ERROR: Unbound variable: menu-snapping
>

This function is not defined.  Most likely you copied a function
or binding that uses it but forgot to copy the function
definition.

>[...]
><<WARNING>> call-interactively: Procedure `scwm-quit' is not interactive.

This is not a big deal.  You can fix it with an (iteractive) declaration
if desired.

>scwmmessages:  fatal IO error 32 (Broken pipe) or KillClient on X server 
>":0.0"