[ANNOUNCEMENT] Server Test 87

[Harold L Hunt II <huntharo at msu dot edu>]

Links:

I just posted Test 87 to the server development page:
http://xfree86.cygwin.com/devel/shadow/

You can install the Test 87 package via setup.exe by selecting the
following version of the XFree86-xserv package:		4.2.0-38

Server Test Series binary and source code releases are now
available via the sources.redhat.com ftp mirror network
(http://cygwin.com/mirrors.html) in the
pub/cygwin/xfree/devel/shadow/ directory.  You may wish to note the
desired filename in the links below, then download from your
closest mirror (http://cygwin.com/mirrors.html).

Server binary, direct link:
http://www.msu.edu/~huntharo/xwin/shadow/XWin-Test87.exe.bz2 (1208 KiB)

Server source, direct link:
http://www.msu.edu/~huntharo/xwin/shadow/xwin-20030529-0045.tar.bz2 (116
KiB)

xc/programs/Xserver/hw/xwin (all files) diff against Test86 source code:
http://www.msu.edu/~huntharo/xwin/shadow/xwin-Test86-to-Test87.diff.bz2 
(11 KiB)


Changes:

1) Convert X application icons set in WM_HINTS from XPMs to Windows
BMPs using an internal algorithm.  Earle, Ralf, and Colin worked
together on this one with coding, suggesting ideas, and testing.  The
end result is, as they say, very nearly perfect.  Each top-level X
window is now given its own class that has an icon associated with it.
The icon can be even changed while the application is running and this
is properly handled.  Icons are properly freed when a window and its
associated class are destroyed.  This entry encompasses a flurry of
emails and patches that I cannot possibly recount here; hopefully no
one feels slighted by this brief summary.  (Earle F. Philhower III,
Ralf Habacker, Colin Harrison)

2) Set XIconSizes() to the Windows approved 16, 32, and 48.  It
doesn't seem to be looked at by anything, but it is in the XLib
documents as something a WM should set.  (Earle F. Philhower III)

3) Removed several misc compile warnings.  (Earle F. Philhower
III)

4) winmultiwindowwindow.c/winTopLevelWindowProc() - Add a call to
winKeybdReleaseKeys () in WM_KILLFOCUS.  This fix stops the phantom
key presses that people were seeing.  The example here would be to
launch an xterm, then launch another xterm from that xterm.  Type
``exit'' in the first xterm and press enter.  The enter keydown
message is processed by the second xterm, but the keyup is never
processed so it got sent repeatedly to the root-level message loop
(which performs all keyboard processing), causing phantom key presses
to show up in any X app that currently had the focus.  At least, I
think that is that the problem was.  An interim solution was to press
and release the enter key, which would cause a keydown/keyup message
combo to be sent, thus ending the crazy looping.  This fix pops all
keys that are pressed when the current X app looses the keyboard
focus.  Colin suggested this, Earle move the location of the call to
the proper place.  (Colin Harrison, Earle F. Philhower III)

5) XWin.rc - Change the Exit Confirmation and Depth Change dialog
boxes to be centered by adding the DS_CENTER flag to the STYLE
attribute.  (Biju G C, Harold L Hunt II)

6) winmultiwindowwindow.c/winTopLevelWindowProc() - Let
DefaultWindowProc() handle the Alt+F4 key combo in the WM_*KEYDOWN
messages.  This allows a user to close a top-level X window (which has
an associated Windows window) by pressing Alt+F4.  Note that this
happens regardless of the -[no]winkill command-line parameter.  This
is the desired behavior since -[no]winkill should only affect the
behavior of the root-level window, not the individual X Client
windows.  (Biju G C, Harold L Hunt II)

7) winwndproc.c/winWindowProc() - Define a WM_GIVEUP message that
calls GiveUp(); remove the GiveUp() call from WM_CLOSE and replace it
with a call to winDisplayExitDialog(), which displays the Exit
Confirmation dialog box.  This only makes sense in conjunction with
the next change log entry.  (Biju G C, Harold L Hunt II)

8) windialogs.c/winExitDlgProc()/WM_COMMAND/ID_OK - Pass WM_GIVEUP to
PostMessage() instead of passing WM_CLOSE.  This patch causes the end
result that, in MultiWindow mode, selecting Close from the system menu
for non-root-level Windows window causes that particular X Client to
be killed.  The previous result was that the XWin.exe process was
exited without displaying the Exit Confirmation dialog box.  This must
have been a frustrating situation indeed and it makes this bug a
marvelous catch on Biju's part.  NOTE: The system menu can be opened
by right clicking on the title bar, or by left clicking the icon in
the upper left-hand corner of the app window, or by right clicking on
the application entry in the task bar.  (Biju G C, Harold L Hunt
II)

9) windialogs.c/winDisplay(Exit)|(ChangeDepth)Dialog() - Call
SetForegroundWindow() if the dialog box has already been created.
This pulls the dialog box to the foreground if it has been buried by
other windows.  It is legitimate to do this here because we are
responding to user input of some sort when this function gets called.
(Harold L Hunt II)

10) XWin.rc - Add the extended style WS_EX_DLGMODALFRAME and the
normal style WS_DLGFRAME to the Exit Confirmation dialog box in an
attempt to stop the dialog box from being listed in the task bar,
which was reported by one user.  This task bar listing has been
negatively confirmed in Windows 2000 and Windows XP, but it may be
happening in other versions of Windows.  Of course, this could have
been a reference to the fact that the dialog is present in the Alt+Tab
list.  However, that is the desired behavior and will not be changed
(how else could you get back to that dialog box?).  (Biju G C, Harold
L Hunt II)

11) Try, in vain, to maintain a uniform coding style and
variable/function naming convention.  I am mostly winning the
curly-brace (curly braces on separate lines please), indenting (emacs
default please), parameter spacing (e.g. func (x, y) instead of
func( x,y ), func( x, y&nbsp), or even func(x,y)), and
binary operator spacing ((x + y) instead of (x+y)) wars, but
I am pitiful excuse for a belligerent dictator when it comes to the
variable naming (follow examples in winwndproc.c), variable prefixing
(follow winwndproc.c, which is my own sick mix of Hungarian prefixes
(int, dw, psz, f) and old-school C prefixes (i, n, l)), and function
naming wars.  I would like to ask all contributors to try to follow
the code that they see in the files that I authored, but I don't feel
that I have the right to reject patches that don't follow those
conventions.  I will, however, try my best to adapt all patches so
that I can read them and more easily maintain them in the future.  You
may also have noticed that I am a profuse commentor... I do that
because I have a very poor memory of why things were done they way
that they were done, so I sprinkle tips throughout the code to help
myself remember things.  You know, I have been realizing the entire
time that I was writing this change log that I have low blood sugar, I
am very tired, and this is so not the place for such huge amounts of
text.  Time for bed.  Change log over.  (Anonymous... Like you have to
guess)


Enjoy,

Harold