Scrollbars patch

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

Jehan,

Implementing a scrollbar patch is quite a bit more complex than you had
initially thought.

I have done a ton of work on the patch and I've got things much more complete
now.  I haven't got time to describe all the changes I made, but here is the
patch against current CVS for you to look over:

http://www.msu.edu/~huntharo/xwin/shadow/xwin-scrollbars-20020710.diff.bz2 (12
KiB)


Okay, I'll give a few highlights:

1) You were passing FALSE for the fRedraw flag to SetScrollInfo in almost
every call that you made to the function.  This had multiple effects,
including causing the thumb position to lag behind the actual scroll location,
causing the thumb size to not update when you changed the page size, etc.

2) The code for WM_VSCROLL and WM_HSCROLL made about 8 sets of calls each to
the same functions with slightly different parameters.  I changed the code to
calculate the parameters first, then make one set of calls to SetScrollInfo
and ScrollWindowEx, etc.

3) I added a flag for fUserGaveHeightAndWidth to indicate that the user
explicity passed a height and width for a given screen.  Now when we are
creating a default-sized window, with -scrollbars, we make the window as large
as possible, and we shrink the underlying X visual to fit within the client
area of the Windows window, without displaying the scrollbars.  We show the
scrollbars if/when the user ever shrinks the window.

4) When a user does specify a visual size with -scrollbars, we make the
initial window as large as possible and make the visual the same size as the
specified size.  We show the scrollbars only if necessary (i.e. we hide them
if the user passes -screen 0 800 600 -scrollbars on a 1024x768 display).

5) You no longer have to specify a width and height for a ``-screen scr_num
[width height]'' parameter, which allows you to do:
XWin -scrollbars -screen 0 -screen 1

This would create two full-sized screens that are resizable but that will not
initially display scrollbars.

6) I added processing for WM_GETMINMAXINFO, in which we update the maximum
tracking size for the window.  The processing in WM_SIZING attempted to do the
same thing, but in actuality it never did anything because it would never see
sizes larger than the initial window size.  The max tracking size is the
largest size that the window is allowed to have when it is not maximized.  We
let the user make the window large enough to display the whole visual, even is
this means that the window will be larger than the current display (just
think, they can move the window around to see the part that they are
interested in... I'm not going to argue with someone that wants to do that). 
This should allow multi-monitor users to create one huge window and stretch it
across a couple of monitors, if they so desire.

7) I added a check to make sure that specified screens are numbered
consecutively from 0.  Screens do not have to be described in order, but there
cannot be any gaps in the screen number sequence once all parameters have been
processed.  This prevents a user from doing ``XWin -screen 1 -scrollbars'' and
then wondering why the window does not have scrollbars (or resizing support).
 This fixes an existing, but subtle, bug that no one seems to have stumbled
across yet.

8) I added WM_MAXIMIZE to the window style when -scrollbars is passed.  This
allows one to maximize the Cygwin/XFree86 window.  However, there are a few
problems here... such as, what is a maximized 800x600 window on a 1024x768
screen?  I dunno... try it, it is weird.

9) WarpCursor is messed up when you use mwm to switch to another virtual
desktop inside of a Cygwin/XFree86 window that is smaller than the underlying
visual and has scrollbars displayed.  In this case, WarpCursor will blast the
cursor to the location on the Windows display where the X location should
be... but that location may actually be scrolled off the Cygwin/XFree86
window.  In those cases I would like to be able to scroll the warp destination
into the Cygwin/XFree86 window, then warp accordingly.  Figuring out how to
get the warp destination into the current scroll viewport may be difficult.

Ah... that's enough for today.  I'm tired.

Harold