Re: Scrollbars patch
Jehan, Here is a new patch and the files that you are missing: http://www.msu.edu/~huntharo/xwin/shadow/xwin-scrollbars-20020711-1128.diff.bz2 (12 KiB) http://www.msu.edu/~huntharo/xwin/shadow/xwin-scrollbars-newfiles-20020711-1128.tar.bz2 (9 KiB) Let me know what you think of the new patch. Answers to questions, etc. are below. 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. Actually, I set FALSE in all cases. If not, then I forgot :). If I did that, it because on my machine it was working well that way, so I didn't want to force Windows to paint the scrollbar twice. Charles Petzold's book says that you only want to pass FALSE if you will be making other function calls that will result in the scrollbars being redrawn, so that you can avoid excessive redrawing. When we call SetScrollInfo with a new position, that is it. We only make that one call that could potentially cause the scrollbar to redraw, so we have to pass TRUE. 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. I thought about doing something like that and then I forgot. And I didn't look at the example in MSDN, I understood the message well enough and usually their examples suck if they compile at all!! (and this one isn't perfect either: they call UpdateWindow in one case but not the other, tsss!!!) I had to clean up the original code, it was spaghetti :) 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). 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. 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. This has nothing to do with the scrollbar, does it? But still a good feature :) It really is related, because we have to make a branch on whether the user explicity told us how large they wanted the X visual. If they explicity specified a visual size then we say, ``okay, that is how big the visual will be, display scrollbars if necessary''. On the other hand, if they just want as big of a window as possible, (such as running ``XWin -scrollbars'') then we will trim the visual size to fit inside of a window without scrollbars, but we allow the window to be resized later, which would result in scrollbars being displayed. If I did not add the ``-screen 0'' functionality, then users would have to pass a size, such as ``-scrollbars -screen 0 1024 768 -screen 1 1024 768'', which would result in two windows that would initially have scrollbars and a 1024x768 visual. The user would have to be very craft in order to figure out, on their own, the largest size window that could be displayed without causing scrollbars to initially be visible. Allowing them to pass ``-scrollbars -screen 0 -screen 1'' allows them to very easily create two windows that are as large as possible with scrollbars initially hidden, but with the ability to resize the window if desired. 6) I added processing for WM_GETMINMAXINFO, in
Re: Scrollbars patch
Harold L Hunt wrote:
Charles Petzold's book says that you only want to pass FALSE if you will be
making other function calls that will result in the scrollbars being redrawn,
so that you can avoid excessive redrawing. When we call SetScrollInfo with a
new position, that is it. We only make that one call that could potentially
cause the scrollbar to redraw, so we have to pass TRUE.
Ok, good to know.
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).
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.
I wanted to but I can't compile for now (missing xf86openConfigFile,
xf86readConfigFile, xf86closeConfigFile at link timeand I don't have
time to look at that yet)
But, a wild guess, isn't ptMaxSize in WM_GETMINMAXINFO for that? (MSDN,
MINMAXINFO: ptMaxSize | when a window is maximized or resized, ...)
I've included a tarball with the missing files above.
Thanks, but I got them already and that why I get this error.
hw/xwin/libXwin.a(winconfig.o)(.text+0x2f6):winconfig.c: undefined
reference to `xf86openConfigFile'
hw/xwin/libXwin.a(winconfig.o)(.text+0x355):winconfig.c: undefined
reference to `xf86readConfigFile'
hw/xwin/libXwin.a(winconfig.o)(.text+0x371):winconfig.c: undefined
reference to `xf86closeConfigFile'
So I have winconfig.c... Ok, found my problem. I didn't patch Imakefile.
I also found an error in the Imakefile.diff for the last test release on
the website. You define XWINPARSELIB but you use XWINPARSERLIB (parse vs
parseR).
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.
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.
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.
j4) Still in wincreatewnd.c, for better clarity, I would write something
like:
if (!(pScreenInfo-fScrollbars pScreenInfo-fUserGaveHeightAndWidth)) {
/* except if the user specified the size of the visual *and*
uses scrollbars, we don't want the visual bigger than
the window */
pScreenInfo-dwWidth =
Re: Scrollbars patch
Jehan [EMAIL PROTECTED] said: Harold L Hunt wrote: 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. I wanted to but I can't compile for now (missing xf86openConfigFile, xf86readConfigFile, xf86closeConfigFile at link timeand I don't have time to look at that yet) But, a wild guess, isn't ptMaxSize in WM_GETMINMAXINFO for that? (MSDN, MINMAXINFO: ptMaxSize | when a window is maximized or resized, ...) I've included a tarball with the missing files above. 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. Now that I can compile and test, here how it works. - ptMaxSize is the maximum size of the window when you press the maximize button. In practice, when you maximzed a window, it takes the min between ptMaxSize, ptMaxTrackSize, and the Windows desktop (at least on my single monitor machine) . - ptMaxTrackSize is the maximum size of the window when dragging a border (or using the size in the system menu). Also, I don't think we want a bigger window than what Windows set (do we wan't the window to be bigger than the Windows (virtual) desktop?) So I suggest that: ptMaxSize = min (ptMaxSize, size of visual) ptMaxTrackSize = min (ptMaxTrackSize , size of visual) Jehan Sort of. On single and uni monitor displays, a maximized window is set to the minimum of ptMaxSize, ptMaxTrackSize, and the size of the windows display area on the current monitor. Oh hell... I give up. I don't know... we will just have to see how people like this when I finally make a test release. We really need someone with 1 monitors on their Windows machine to help out here... Harold
Re: Scrollbars patch
Jehan [EMAIL PROTECTED] 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. 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. 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. I wanted to but I can't compile for now (missing xf86openConfigFile, xf86readConfigFile, xf86closeConfigFile at link timeand I don't have time to look at that yet) But, a wild guess, isn't ptMaxSize in WM_GETMINMAXINFO for that? (MSDN, MINMAXINFO: ptMaxSize | when a window is maximized or resized, ...) I've included a tarball with the missing files above. Thanks, but I got them already and that why I get this error. hw/xwin/libXwin.a(winconfig.o)(.text+0x2f6):winconfig.c: undefined reference to `xf86openConfigFile' hw/xwin/libXwin.a(winconfig.o)(.text+0x355):winconfig.c: undefined reference to `xf86readConfigFile' hw/xwin/libXwin.a(winconfig.o)(.text+0x371):winconfig.c: undefined reference to `xf86closeConfigFile' So I have winconfig.c... Ok, found my problem. I didn't patch Imakefile. I also found an error in the Imakefile.diff for the last test release on the website. You define XWINPARSELIB but you use XWINPARSERLIB (parse vs parseR). Yeah, I caught that problem in the Xserver/Imakefile when I went to do a build on another system that hadn't already built the parser. 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. 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? 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
Re: Scrollbars patch
Harold L Hunt wrote: Jehan [EMAIL PROTECTED] said: Harold L Hunt wrote: 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. I wanted to but I can't compile for now (missing xf86openConfigFile, xf86readConfigFile, xf86closeConfigFile at link timeand I don't have time to look at that yet) But, a wild guess, isn't ptMaxSize in WM_GETMINMAXINFO for that? (MSDN, MINMAXINFO: ptMaxSize | when a window is maximized or resized, ...) I've included a tarball with the missing files above. 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. Now that I can compile and test, here how it works. - ptMaxSize is the maximum size of the window when you press the maximize button. In practice, when you maximzed a window, it takes the min between ptMaxSize, ptMaxTrackSize, and the Windows desktop (at least on my single monitor machine) . - ptMaxTrackSize is the maximum size of the window when dragging a border (or using the size in the system menu). Also, I don't think we want a bigger window than what Windows set (do we wan't the window to be bigger than the Windows (virtual) desktop?) So I suggest that: ptMaxSize = min (ptMaxSize, size of visual) ptMaxTrackSize = min (ptMaxTrackSize , size of visual) Jehan Sort of. On single and uni monitor displays, a maximized window is set to the minimum of ptMaxSize, ptMaxTrackSize, and the size of the windows display area on the current monitor. Min(ptMaxSize, ptMaxTrackSize) seems logical (assuming that Windows is logical ;p). Why wouldn't someone be able to resize his window at least as big as the maximized one would be?. That it trims to the desktop size. Well it make sense in a way. Image that one of your monitor is 640x480 and this other is 1024x768. The second monitor being on the size of the other (by opposition to top/bottom). _ | 640 | 1024 | |_480_| 768 | |___| What is the maximized size? 640+1024 by max(480,768)? Then some part would not be visible (lower left). (640+1024) by min(480,768)? Then the lower right isn't used. I would say then, we takes what Windows behavior and we make it more restrictive if necessary, i.e. we reduce the size if the visual is smaller that what the window would be. Oh hell... I give up. I don't know... we will just have to see how people like this when I finally make a test release. We really need someone with 1 monitors on their Windows machine to help out here... If you can't find someone to do it, I have a system where I could test. But I prefer to avoid touching that machine as much as possible. This is a demo machine at work, I don't really want to install anything that is not necessary (and cygwin isn't).
Scrollbars patch
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
Re: Scrollbars patch
Harold L Hunt wrote: 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. Actually, I set FALSE in all cases. If not, then I forgot :). If I did that, it because on my machine it was working well that way, so I didn't want to force Windows to paint the scrollbar twice. 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. I thought about doing something like that and then I forgot. And I didn't look at the example in MSDN, I understood the message well enough and usually their examples suck if they compile at all!! (and this one isn't perfect either: they call UpdateWindow in one case but not the other, tsss!!!) 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). Hiding the scrollbars, that was already the case, wasn't it? 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. This has nothing to do with the scrollbar, does it? But still a good feature :) 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. I didn't know this message, or actually I forgot. That's more elegant for sure. 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. Same comment as 5). :p 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. I wanted to but I can't compile for now (missing xf86openConfigFile, xf86readConfigFile, xf86closeConfigFile at link timeand I don't have time to look at that yet) But, a wild guess, isn't ptMaxSize in WM_GETMINMAXINFO for that? (MSDN, MINMAXINFO: ptMaxSize | when a window is maximized or resized, ...) 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...
