[try 3] systray patches

[Kirill K. Smirnov]

> > Or I miss something really important? If so, just provide a use-case,
> > please!!
>
> Well, for instance if the parent is a Wine window, which would be the
> case when someone implements systray handling in desktop mode, it
> would break since Wine windows are not painted with the background
> pixmap.

This case assumes absolutely other mechanism of embedding, not XEMBED.
_Wine_ cannot be XEMBED-master for _wine_ application. (May it? Reasons?)

My patches are to fix annoying background situation caused by _XEMBED_ usage. 
Only for xembed.

Other way (as you supposed, native wine's tray in desktop mode) may be 
implemented (interesting idea, I though about it, but is there anybody who 
needs this?). Then XEMBED and the new mechanism MUST be mutually excluse.

So, my patch does not hurt anything.

> Anyway, I'm not necessarily opposed to doing pseudo-transparency, if
> you can find a way to do it cleanly, i.e. without adding special cases
> for systray windows all over the place.

  Heh, I intend to add cases as less as possible!
BUT!
 For any "output-only-transparency, not input" mechanism for XEMBED I choose, 
I have to play around with background pixmap.

When application changes icon, the window background must be repainted to 
remove previous junk. As you say,  Wine windows are not painted with the 
background pixmap (I do not know details), so we must do it explicitly by 
calling XClearWindow.

This is reason for at least one special case handling.

And I add one special case in SetWindowIcon at winex11.drv/window.c!!!

Other case I added in user32/defwnd.c looks like hack.
You were right - I should investigate SetWindowPos problem.

-- Kirill