Re: wine/ windows/winpos.c server/window.c server/ ...
Hello Alexandre, I see, you implemented storage of the four global shell and takman windows. Btw.: great unified aproach, this single get/set server call. :) But you did not yet insert the altered focus handling in set_active_window() from my patch. Is this just comming next, or is there another particular reason for not doing this? Martin On 07.10.2003 05:40:24 Alexandre Julliard wrote:
ChangeSet ID: 9656 CVSROOT: /home/winehq/opt/cvs-commit Module name: wine Changes by: julliard(a)wine.codeweavers.com 2003/10/06 22:40:24
Modified files: windows : winpos.c server : window.c trace.c request.h protocol.def include/wine : server_protocol.h dlls/user : focus.c
Log message: Store the global shell, progman and taskman windows in the server (based on a patch by Martin Fuchs).
Patch: http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=9656
Old revision New revision Changes Path 1.147 1.148 +0 -81 wine/windows/winpos.c 1.23 1.24 +61 -0 wine/server/window.c 1.182 1.183 +20 -0 wine/server/trace.c 1.88 1.89 +2 -0 wine/server/request.h 1.84 1.85 +18 -0 wine/server/protocol.def 1.85 1.86 +27 -1 wine/include/wine/server_protocol.h 1.5 1.6 +131 -0 wine/dlls/user/focus.c
Martin Fuchs <martin-fuchs(a)gmx.net> writes:
But you did not yet insert the altered focus handling in set_active_window() from my patch. Is this just comming next, or is there another particular reason for not doing this?
Well, I'm not convinced we need to do such special handling at all; why did you have to add that? And if we really need it we should find a better way, to avoid adding yet more server calls in that code path. -- Alexandre Julliard julliard(a)winehq.com
But you did not yet insert the altered focus handling in set_active_window() from my patch. Is this just comming next, or is there another particular reason for not doing this?
Well, I'm not convinced we need to do such special handling at all; why did you have to add that?
The shell window is that window, you can see at the background of the desktop. Any other window has to be in front of this window. So I refuse to move the shell window in the foreground when this is tried by calling set_active_window(). The problem with this all is, that SetShellWindow[Ex] is documented nowhere. So we have to guess, what is the correct behaviour. Also we don't have very many test cases... Just this one shell window on the MS Windows desktop. Only this is using SetShellWindowEx(). When trying to get my explorer clone to work on Wine, I found this way to make it work in Wine's desktop mode. I am also not really sure if this is the only or the best way to do it. But it works. Without this patch there exists this problem: Whenever you click onto the desktop, the shell window is moved into the foreground, in front of any other 'normal' window. Even the task bar becomes invisible, because it is hidden behind the desktop. However in non-desktop mode it does not yet work correctly even with the patch. I don't know, what's exactly the problem. It displays only a white desktop background - it should be green. And it can't display any other window in front of the white desktop. Do you know, what is going on there? If you want, you can try to launch explorer with wine - you can download it from my "Explorer FAQ" page.
And if we really need it we should find a better way, to avoid adding yet more server calls in that code path.
On MS Windows there is used a region of shared memory mapped read-only from the kernel space into user space of each process. This memory region contains for example the information about the shell window. This way it is possible to avoid a call into kernel, just to get the shell window. Do you think, such a thing would also be possible in Wine? By the way: I had to introduce a special work around for Wine in Explorer to make the task bar display at all. Wine behaves a little bit different when creating windows while processing a WM_CREATE message of it's parent window. It seemed to me, the order of sent messages is not exactly the same as in MS Windows. But I did not look too deep into this, as I found a work around. Martin
Martin Fuchs <martin-fuchs(a)gmx.net> writes:
When trying to get my explorer clone to work on Wine, I found this way to make it work in Wine's desktop mode. I am also not really sure if this is the only or the best way to do it. But it works. Without this patch there exists this problem: Whenever you click onto the desktop, the shell window is moved into the foreground, in front of any other 'normal' window. Even the task bar becomes invisible, because it is hidden behind the desktop.
If the problem is only with your app, then it can be fixed there. Probably handling WM_MOUSEACTIVATE should do the trick. I also think the SetWindowPos calls in SetShellWindow should be moved into your app.
On MS Windows there is used a region of shared memory mapped read-only from the kernel space into user space of each process. This memory region contains for example the information about the shell window. This way it is possible to avoid a call into kernel, just to get the shell window. Do you think, such a thing would also be possible in Wine?
At some point we'll probably do something like that yes. -- Alexandre Julliard julliard(a)winehq.com
On Tue 7. October 2003 22:15, Alexandre Julliard wrote:
Martin Fuchs <martin-fuchs(a)gmx.net> writes:
When trying to get my explorer clone to work on Wine, I found this way to make it work in Wine's desktop mode. I am also not really sure if this is the only or the best way to do it. But it works. Without this patch there exists this problem: Whenever you click onto the desktop, the shell window is moved into the foreground, in front of any other 'normal' window. Even the task bar becomes invisible, because it is hidden behind the desktop.
If the problem is only with your app, then it can be fixed there. Probably handling WM_MOUSEACTIVATE should do the trick. I also think the SetWindowPos calls in SetShellWindow should be moved into your app.
The problem is not just my application. The problem exists with any application, that tries to register a shell window, for example the original MS explorer or GeoShell. Handling it with catching WM_MOUSEACTIVATE would be possible, yes. But that would be another work around especially for Wine. If it is launched on a bare MS windows system without MS explorer, it registers it`s shell window and there is no problem with focus handling. I think, Wine should behave the same way? ROS explorer is targeted to be a replacement for MS explorer. So it should behave in the same way. This means, also its problems may be reproduced. So I would like to avoid any work arounds, as far as it is possible.
On MS Windows there is used a region of shared memory mapped read-only from the kernel space into user space of each process. This memory region contains for example the information about the shell window. This way it is possible to avoid a call into kernel, just to get the shell window. Do you think, such a thing would also be possible in Wine?
At some point we'll probably do something like that yes.
Good. Which other global informations would be cancdidates for this? May be we could start right now to use this shared memory technique. -- Martin Fuchs martin-fuchs(a)gmx.net
Martin Fuchs <martin-fuchs(a)gmx.net> writes:
The problem is not just my application. The problem exists with any application, that tries to register a shell window, for example the original MS explorer or GeoShell. Handling it with catching WM_MOUSEACTIVATE would be possible, yes. But that would be another work around especially for Wine. If it is launched on a bare MS windows system without MS explorer, it registers it`s shell window and there is no problem with focus handling. I think, Wine should behave the same way?
Yes, if it works under Windows then obviously we need a fix in Wine. I think you should investigate exactly how Windows does it, there are many places where we could add such checks so we need to find out exactly where Windows has them.
Good. Which other global informations would be cancdidates for this? May be we could start right now to use this shared memory technique.
No, I want the code to work right with the current scheme before we start adding shared memory, because it will create a lot of subtle synchronization problems. -- Alexandre Julliard julliard(a)winehq.com
participants (2)
-
Alexandre Julliard -
Martin Fuchs