[try 3] systray patches
Kirill K. Smirnov
lich at math.spbu.ru
Tue Jan 9 11:52:36 CST 2007
> > 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
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!
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
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.
More information about the wine-devel