"Kirill K. Smirnov" lich@math.spbu.ru writes:
Please, explain me, what is wrong with this serie of patches? What to do to improve them?
As I said, making the background pixmap ParentRelative is just a hack, it's not real transparency.
Why is it not a real transparency? This is the easiest way to provide only output transparency, not input. Exactly what we need.
You don't know how the parent will paint itself, so you can't rely on that.
wine doesn't know that, but does not need to know too. That's why I use ParentRelative, because when I change KDE (e.g.) panel background it is handled correct.
Also, your patch adds special handling for the tray window in user32, that's a violation of the driver abstraction.
Hm... The core problem here is to notify WM systray to be repainted when wine changes icon. To achieve this, I call XClearWindow in setwindowicon@winex11.drv/window.c. This is ideological correct (IMO) - perform X operation in setwindowicon function when application changes icon. But!!! defwndproc@user32.defwnd calls SetWindowPos. This breaks everything concerning wine tray. Tray window should not be reposed. It is done once (while docking) and forever.
So, my patch for user32 is a 'bugfix' for a 'bug' caused by wine systray embedding idea.
Maybe, there is other way to achieve this, but I cannot imagine.
Any ideas?
-- Kirill
"Kirill K. Smirnov" lich@math.spbu.ru writes:
Why is it not a real transparency? This is the easiest way to provide only output transparency, not input. Exactly what we need.
It's not transparent, it's painted with what you hope is the same background as the parent, but there's no guarantee of that.
So, my patch for user32 is a 'bugfix' for a 'bug' caused by wine systray embedding idea.
No, it's just a hack. The first thing to do is understand why moving the systray window would break something.
-
Alexandre Julliard -
Kirill K. Smirnov