Hooks which take wrong number of params cause seg faults!
--07/04/98 gjb
-------------
Incorrect usage of keyword arguments by a scheme function fails silently.
Both wrong keyword names and missing arguments should be reported.
-------------
Race conditions cause scwm to hang when talking to fvwm2 modules when, e.g.,
recapturing.
-------------
1. I pop up an xterm
2. I do a horizontal-toggle-maximize
3. I change to a smaller font.
4. The window automatically resizes due to 3, preserving the number of rows & columns.
5. I do a horizontal-toggle-maximize again to bring it back to normal size.
6. The window resizes to many more rows and columns than it originally
   had.  It ends up about the same size in pixels, though.

Evidentally toggle-maximize isn't differentiating between windows
sized in characters & windows sized in pixels.

Shouldn't toggling back to the original size go back to the orignal
number of rows & columns, not the original size in pixels?  If I
recall correctly, that's what fvwm does.
   hstein - 7/16/98
-------------
Visual bugs in boundaries of windows with some configurations of options.
-------------
wildcard-matcher in wininfo doesn't permit distinguishing based on title,
class, and resource name separately.  This is essential for window styles
to do the right thing (a misfeature compared to fvwm2)
-------------
Some error messages are looked up in a table that is distant from the error.
---------------
icon-box not honoured, moving icons moves windows
-------------
popup-menus attached to decorations come up centered over the click, instead of 
flush with the window edge
---------------
xdvorak's change mapping should cause all keybindings to be reset and
new keycodes to be gotten
---------------
Windows still aren't positioning correctly for me at startup.  They're
starting too low (when positioned with -0, as in:

xterm -j -sb -sl 128 -si -geometry 82x48-0-0 -T $XTERMNAME &
xterm -j -sb -sl 128 -si -geometry 80x24+0-0 -T $XTERMNAME &

The 1st xterm also ends up a little to far to the right (looks like
it's off by the window border).

This is with "guile 1.3a" (snap 980630), & a cvs update this morning
of scwm.

--hjstein
-------------
I've noticed this off-and-on with 0.6, and just noticed again with
0.7: My xterms have #:focus 'sloppy set; sometimes (probably about
one time in 25), when I have a pair of partially overlapping
windows and I move the cursor quickly from the root window,
crossing one of the xterms (which held the sloppy focus), and
landing in the other xterm, the new window does not gain focus.
I have to take the cursor off of the window in which I desire
focus and bring it back in, crossing the border slowly.

Ken Pizzini

-------------
windows having a different border-width than the default (6) are
placed incorrectly if they have SE gravity. They are several pixels
[(6-border_width)*2] off the screen-border.

This is due to the fact that `PlaceWindow' is called before the
evaluation of window-styles. `PlaceWindow' needs to be called if the
border-width changed (from `set_border_width_x', or `SetupFrame', or
whatever). It would be nice if the call to `PlaceWindow' before the
window is properly styled could then be removed, but I don't know what
this could break.

	Robert Bihlmeyer
------------
- Another window shade problem: clients that resize themsleves while
shaded make the wm lose. [ reported by Oleg Tihnov ]
------------
- Click to focus bugs

1a. At startup usually a window, which I don't want given focus,
   gets focus.

1b. The same is true on a restart.  Except sometimes no window gets
   focus at all, which makes life difficult for `next'.

2. When I quit a X app, the focus is usually given to a window I don't 
   want to have focus.

Jens


Possibly stop making resizes account for decorations, so that maximize
is happier.

callbacks should run from a new dynamic root. [ huh? --11/08/97 gjb ]
[ this would prevent them from calling continuations that escape
outside the callback handler - the code would lose big on this -ms]


----------------------------------------------------------------------
RESOLVED:
----------------------------------------------------------------------

gjb gets this on recapture
[Scwm][ScwmErrorHandler]: <<ERROR>> Request 54, Error 4, EventType: 2
                                    XFreePixmap 
This could be due to the recapture code losing track of the pixmap due
to some change I made in the pixmap code --11/08/97 gjb
Not reproducible any longer --08/02/98 gjb


- Animated window-shade bug, reported by Sam Steingold <sds@usa.net>,
exploit confirmed by MS, but I have no clue how to fix it right now:
Open 2 windows, one (1) partially obscuring the other's (2) title bar.
Double click on the (1)'s title bar, shading it.  You can see that the
portion of the (2)'s title bar with was obscured before but it not
obscured now is not repainted.  Also, if you move the mouse towards (2)
while (1) is being (animatedly ==> with delay) shaded, so that the (1)
is "pulled from under the mouse pointer", leaving it on (2), (2) will
*not* have the focus, although it should as per sloppy focus.
--03/10/98 gjb; XSync was discarding events, and we needed a CoerceEnterNotifyOnCurrentWindow() to restore proper focus 


- Jim Blandy's patch to load boot-9 for newer guile versions is
problematic; it can't tell wether or not we are running under an older
guile which has already loaded boot-9, resulting in a segfault. - MS
[fixed for now - MS]

- buggy icon handling everywhere -- needs thorough testing
  -- 2-20-97 mstachow

should initially focus/hilight some window (also a bug in fvwm2)
  -- Fixed by adding CoerceEnterNotifyOnCurrentWindow()

Memory allocation errors can occur if guile was built with Rx support;
autoconf sets this option if it finds a librx.{a,so} in the paths it
checks. --11/08/97 gjb

Passing a bad window from guile can cause scwm to dump core in
ensure_valid(); MS says fixed ~ 11/1/97


functions should be renamed to end with _x 
  -- This looks done... is it not? --11/08/97 gjb	

(get-window) acts wierdly when a window needs to be selected, or
when executed via scwmsend's property mechanism -- was a problem with
DeferExecution();  not sure if it's completely right now, but seems to
work in the cases I've tried -- 10/25/97, gjb

there needs to be a way to remove mouse bindings; unbind_key added 10/24/97, gjb

start interactive moves and resizes right, so that initial mouse motion is not
lost.  ~ 10/15/97, MS

Oleg Tihonov <oleg@benetnash.ffke-campus.mipt.ru>'s bug re: bind-mouse
and unbind-mouse.  bind-mouse grabbed for all windows unnecessarily, and 
unbind-mouse did not permit `1' to mean moust button 1 --gjb 11/27/97 
