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
Peter Dons Tychsen donpedro@tdcadsl.dk 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.
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
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
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
Peter Dons Tychsen donpedro@tdcadsl.dk 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.
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
Peter Dons Tychsen donpedro@tdcadsl.dk 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.
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
-
Alexandre Julliard -
Peter Dons Tychsen