shell window activation

Martin Fuchs martin-fuchs at gmx.net
Tue Oct 7 14:49:35 CDT 2003


> > 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




More information about the wine-devel mailing list