Re: Scrollbars patch

[Jehan <nahor at bravobrava dot com>]

Harold L Hunt wrote:
> Jehan <nahor@bravobrava.com> said:
>
>
> > Harold L Hunt wrote:
> >
> > > > > 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).
> > > > Hiding the scrollbars, that was already the case, wasn't it?
> > > No.  I never got the original code to stop displaying scrollbars if the
> > > -scrollbars parameter was passed.  It didn't matter how large the original
> > > window was, nor did it matter how you resized the window.  I could not get
> > > those scrollbars to go away.
> > Hmm, that's weird. I was even explicitly hiding the scrollbars with a 
> > call to ShowScrollbars (not at creation but in WM_SIZE).
>
> I never saw anything in the code that looked like it would actually result in
> a call to ShowScrollbars.  What I mean is, I didn't see a way that the logic
> values would be such that the call would actually happen.
line 593-597 in the patch file itself.
	if ((iWidth >= s_pScreenInfo->dwWidth)
	    && (iHeight >= s_pScreenInfo->dwHeight))
	  {
	    /* Scrollbars are not necessary, hide them */
	    ShowScrollBar (hwnd, SB_BOTH, FALSE);
	  }

So except if Windows shows back the scrollbar because I didn't change 
nPage, it should hide them if the window is big enough. At least it 
worked on my WinXP machine.


> One question, are you using an auto-hide taskbar?  If not, you might want to
> test your original patch when you use auto-hide.  We trim the work area
> differently when auto-hide is enabled, which could have been causing a problem
> with the original code.
No, I don't have auto-hide for the taskbar. But I do have auto-hide for 
some toolbar on the right of my monitor.

Anyway, the patch you sent me this morning works for the couple quick 
run I did. So all is well :)


> > > We can't make ptMaxSize larger than our visual size, because we could have an
> > > 800x600 visual on a 1024x768 display... we would end up with several thousand
> > > blank pixels if we really maximized the window.  That is the weirdness that I
> > > was talking about.
> > I'm not saying to make it larger than the visual. I think you should set 
> > to the size of the visual. So when some one maximize the window, it will 
> > get the visual and no more. The maximum size of the window should 
> > 800x600 (+decoration if any) and that's it.
>
> That sounds like what I am having it do right now.  But maximizing a window to
> be 800x600 on a 1024x768 display is kinda funny, because Windows positions the
> window such that the top and left borders are off the screen, but the right
> and bottom borders still display because our window isn't large enough to
> cover the whole desktop in this case.
You can use ptMaxPosition. This is to position the window when 
maximizing it. So maybe we could try to center the window on the screen.


> On a side note, I am not currently disallowing moving the window when
> maximized, which seems to be the normal thing to do.  But do we disallow
> moving the window when we maximize an 800x600 window on a 1024x786 display?  
> Seems like that would just confuse users.  Maybe immediately after maximizing
> such windows, we should tell Windows that our window is not maximized, so that
> the ``restore'' button will switch back to a ``maximize'' button, even though
> we are in the maximized position and at maximum size.
>
> What do you think?
I don't think it will work. If you restore the window, the window will 
shrink back to it old size and move to the old position. Moreover, one 
annoying thing I have here, is that some fullscreen application forces 
the windows to resize. The windows were maximized, they stay maximized, 
if they were not, their size is reduced. So I have a few application 
that are by default maximized so that I don't have to worry about it 
anymore.
In a more broader way, changing the default Windows behavior is not 
something I'm in favor for. This can become confusing and be the kind of 
mess we have with Unix with the different set of widgets.

Also, I noticed that if the maximized window occupies the whole desktop 
(i.e. is has big as possible) you can't move the window but if it isn't 
then you can. (try "Xwin -screen 0 1800 1600" vs "Xwin -screen 0 800 600").

So my conclusion is: we should leave it the way it right now and fix it 
if there are lots of complaints.


> > > > j1) in WM_SIZE, you check for fDecoration and fFullscreen for breaking.
> > > > This is not necessary maybe even dangerous, especially in the
> > > > nodecoration case. With nodecoration, I guess we can still receive a
> > > > WM_SIZE if we change the screen resolution via the Display control panel
> > > > or if we change the size of the taskbar.
> > > > And the other hand, I don't thing we'll get any bug if we still do
> > > > process WM_SIZE.
> > > > Well, let's say that, as a matter of preference, I usually manage
> > > > unlikely cases if the code necessary to do it doesn't make my code
> > > > harder to read.
> > > I was assuming that you had intended for scrollbars to be allowed only when
> > > not fullscreen and with decorations.  I know you didn't intend for scrollbars
> > > to be displayed in fullscreen mode because you didn't modify
> > > winCreateBoundingWindowFullScreen.  I don't see any reason why we should
> > > disallow scrollbars when there are no window decorations.  I'll readd that
> > > functionality in the near future.
> > Since if fullscreen mode we change the resolution of the monitor, there 
> > is no need for scrollbars. That's why I didn't modify 
> > winCreateBoundingWindowFullScreen. I actually modify InitOuput to ignore 
> > -scrollbars if -fullscreen was set.
> > But checking for fFullscreen in WM_SIZE isn't necessary then because 
> > fScrollbars will be FALSE.
> > And if one day we allow a different size for the monitor than for the 
> > visual (something like XWin -screen 0 1600 1200 -fullscreen 1280 1024), 
> > it would be better to just check fScrollbars and be fullscreen agnostic.
>
> Ah... except if we change the resolution with the Shadow GDI engine in
> fullscreen (``-engine 1'').  Shadow GDI essentially displays a topmost window
> without decoration.  We can't change the Windows display resolution/depth when
> running the Shadow GDI engine, so the user gets whatever resolution/depth they
> are currently running Windows at.  Thus, if they change the Windows resolution
> they will shrink the size available to the Shadow GDI engine... in which case
> we would need to display scrollbars.  I think that the current behavior is to
> crash or do some undefined things :)
So all the more reason to remove the unecessary constraint on WM_SIZE 
and to handle the fullscreen mode in it even if it's not supported for now.
And adding scrollbars to fullscreen would then be just a matter (more or 
less) to allow fScrollbar to be TRUE in fFullscreen.


> > In the case of nodecoration, nothing prevents one to have something like:
> > 	XWin -scrollbars -screen 0 1600 1200
> > on his 640x480 monitor. Then we must have scrollbars or we have to 
> > reduce the size of the visual.
> I don't understand.  Did you mean to pass -nodecoration as well?
Yes. Sorry. But you added an unecessary "-scrollbars" in your command 
line last time, so I had to compensate and not put a mandatory 
"-nodecoration" this time :p.


	Jehan