Winamp disappears when you move it's location

[Peter Dons Tychsen]

I am posting your response, as you are not on CC in the bug.
> > You can't do that sort of thing. If you really don't want the window

manager to
> > control the windows there's an option for it, but you can't have it both ways.

I am not sure i agree. Everywhere i looked they referred to "override_redirect"
as being *the way* to control this. And doing so is totally valid.

The xlib manual is very clear on this:

"To control window placement or to add decoration, a window manager often needs
to intercept (redirect) any map or configure request. Pop-up windows, however,
often need to be mapped without a window manager getting in the way. To control
whether an InputOutput or InputOnly window is to ignore these structure control
facilities, use the override-redirect flag."

I think this says it all...

http://tronche.com/gui/x/xlib/window/attributes/override-redirect.html

I also checked the source code for Metacity, which only confirmed my findings.
Notes and code to support the statement above was in place.

Please consider this, as it makes some apps look so much better.

Thanks,

/pedro

[Alexandre Julliard]

Peter Dons Tychsen  writes:
> I am posting your response, as you are not on CC in the bug.
> > > You can't do that sort of thing. If you really don't want the window
>
> manager to
> > > control the windows there's an option for it, but you can't have it both ways.
>
> I am not sure i agree. Everywhere i looked they referred to "override_redirect"
> as being *the way* to control this. And doing so is totally valid.

Absolutely not. You can do it at window creation time, but you can't
change the window back and forth just because you want some move request
to not be intercepted. If the window is under control of the window
manager then it has to receive all requests and handle them as it sees
fit.

[Peter Dons Tychsen]

Hello,
> You can do it at window creation time, but you can't 
> change the window back and forth just because you want some move request
> to not be intercepted.

Eh? Did you read the xlib manual i linked to? This is *exactly* what
they recommend for this type of scenario:
http://tronche.com/gui/x/xlib/window/attributes/override-redirect.html
> Absolutely not.

Hmm... :-)

So... i have investigated other ways of fixing this. Would you accept a
patch that uses _NET_WM_MOVERESIZ to move the window? That might also
fix the issue. That message requests the WM to move the window at not X.

Thanks,

/pedro

[Peter Dons Tychsen]

On Tue, 2009-10-06 at 14:37 +0200, Peter Dons Tychsen wrote:
> Hello,
> > You can do it at window creation time, but you can't 
> > change the window back and forth just because you want some move request
> > to not be intercepted.
>
> Eh? Did you read the xlib manual i linked to? This is *exactly* what
> they recommend for this type of scenario:
> http://tronche.com/gui/x/xlib/window/attributes/override-redirect.html

OK, reading it again i must admit it does not say that they recommend
changed it on-the-fly. I often read between the lines even if there is
nothing there.... :-). It would also generate extra X traffic.

Thanks,

/pedro

[Peter Dons Tychsen]

> So... i have investigated other ways of fixing this. Would you accept a
> patch that uses _NET_WM_MOVERESIZ to move the window? That might also
> fix the issue. That message requests the WM to move the window at not X.

I have now tested with _NET_WM_MOVERESIZ & _NET_MOVERESIZE_WINDOW
No cigar. They still have the same problem.

I have also discovered a major problem in the X11 driver which is
affecting this problem (winamp). The mouse code uses the relative
coordinates of the window and compares it to the cached value in
"whole_rect" and "client_rect". There are 2 problems here:

1) "whole_rect" and "client_rect" do not reflect the actual state of the
window, as X might not have processed the request yet. These values
should at least be updated on ConfigureNotify instead which signals that
X has completed (and accepted) the request.

2) Using the relative coordinates from X is not a good idea, as you do
not really know where the window is at that point. Instead the same
message also supplies a "x_root" and "y_root" value. I did an experiment
where i used these values instead of the other to calculate the mouse
coordinate. This had an amazing effect on the stability and the
smoothness when moving windows in e.g. Winamp. I did have problems with
the virtual desktop though, but that can probably be fixed.

Apart from this i am not really sure where the is a "window_rect" and
"whole_rect" as they are both overwritten with the same value every time
X11DRV_WindowPosChanged() is called.

As you did not like my initial attempt to fix the problem, please advise
which route you would approve of.

Thanks,

/pedro

[Alexandre Julliard]

Peter Dons Tychsen  writes:
> > So... i have investigated other ways of fixing this. Would you accept a
> > patch that uses _NET_WM_MOVERESIZ to move the window? That might also
> > fix the issue. That message requests the WM to move the window at not X.
>
> I have now tested with _NET_WM_MOVERESIZ & _NET_MOVERESIZE_WINDOW
> No cigar. They still have the same problem.
>
> I have also discovered a major problem in the X11 driver which is
> affecting this problem (winamp). The mouse code uses the relative
> coordinates of the window and compares it to the cached value in
> "whole_rect" and "client_rect". There are 2 problems here:
> - "whole_rect" and "client_rect" do not reflect the actual state of the
>
> window, as X might not have processed the request yet. These values
> should at least be updated on ConfigureNotify instead which signals that
> X has completed (and accepted) the request.
> - Using the relative coordinates from X is not a good idea, as you do
>
> not really know where the window is at that point. Instead the same
> message also supplies a "x_root" and "y_root" value. I did an experiment
> where i used these values instead of the other to calculate the mouse
> coordinate. This had an amazing effect on the stability and the
> smoothness when moving windows in e.g. Winamp. I did have problems with
> the virtual desktop though, but that can probably be fixed.
>
> Apart from this i am not really sure where the is a "window_rect" and
> "whole_rect" as they are both overwritten with the same value every time
> X11DRV_WindowPosChanged() is called.
>
> As you did not like my initial attempt to fix the problem, please advise
> which route you would approve of.

What you should do first is spend a lot more time studying the code,
before deciding that it has "major problems" and needs major
changes. It's a very sensitive area where the smallest change has big
consequences, and you have to be sure to know what you are doing.

[Peter Dons Tychsen]

> What you should do first is spend a lot more time studying the code,
> before deciding that it has "major problems" and needs major
> changes. It's a very sensitive area where the smallest change has big
> consequences, and you have to be sure to know what you are doing.

I already spent time on this code. 
So your comment does not really help in any way.

Do you at least understand my comments? If not then please state that.
Just stating that i should look at it again does not bring anything to the table.

There were 3 questions/statements in the mail.
Answering at least one of them would be constructive.
> needs major changes

I never stated that it needs major changes. But yes, winex11.drv is a bit messy if you ask me.

Thanks,

/p

[Alexandre Julliard]

Peter Dons Tychsen  writes:
> > What you should do first is spend a lot more time studying the code,
> > before deciding that it has "major problems" and needs major
> > changes. It's a very sensitive area where the smallest change has big
> > consequences, and you have to be sure to know what you are doing.
>
> I already spent time on this code. 
> So your comment does not really help in any way.
>
> Do you at least understand my comments? If not then please state that.
> Just stating that i should look at it again does not bring anything to the table.

Yes I understand your comments, but they show that you don't understand
the code.
> There were 3 questions/statements in the mail.
> Answering at least one of them would be constructive.

You can answer all 3 of them by studying the code, which you'll have to
do anyway if you want to fix it. If you don't want to do that, then
write a test case demonstrating the broken behavior and leave it for
someone else to fix.

[Peter Dons Tychsen]

> Yes I understand your comments, but they show that you don't
> understand
> the code.

Of course i dont understand the code as well as you, as i only have used
a little amount of time studying it.

I was only hoping that my comments would spark a response which would
allow me continue with the bug quicker. Instead you just keep stating the
obvious which is that i do not know the code very well.

I will use more time on it when possible or drop it.

Thanks,

/pedro