Re: XMoveWindow()
On Thu, Mar 4, 2010 at 12:20 PM, Shachar Shemesh shac...@shemesh.bizwrote: Erez D wrote: On Wed, Mar 3, 2010 at 5:05 PM, Shachar Shemesh shac...@shemesh.bizwrote: Erez D wrote: when i write a program, i expect to get the same behaviour which doesn't depend on the WM. however: Traditional window managers reparent the window, and add the titlebar to the parent. compize on the other hand doesn't reparent the window, so the behaviour is different. Yes, but that's avoiding Nadav's question, which was - why is this something for the program to do? i have two displays i want one to be a copy of the other, so when i move a window on one display, i want it to move to the same position in the other. Then it seems to me that you are trying to move the wrong window. Why not run XMoveWindow not on the window you opened, but walk up the parents until you reach the window whose parent is root, and move that one? if i put the parent at x,y - it will place it at x,y. but that not what i want. if i put my original toplevel at x,y - i would expect it to be placed at x,y. but no, it places it's parent at x,y, which means it is placed in an offset. the bottom line: it doesn't matter if i put my window at x,y or it's parent (that belongs to the WM) at x,y - i get the same result. which is not the result i want. btw. if i use compiz - it doesn't have a parent. anyway, an app doesn't need to play it differently if it have or doesn't have a WM, or to be dependant on which WM it has. i woudld expext the folowing line: XTranslateCoordinates(...,win,root,0,0, x, y, ...) ; XMoveWIndow(win,x,y) to do nothing. Then you would be wrong. The x, y are supposed to be relative to the coordinate system in which the window reside. Even without the window manager override, the above command would not work with reparented windows. yes it will. E. No it won't? The x,y for a reparented window are relative to its parent. If you treat them as relative to the root window, your XMoveWindow will, almost always, move your window way too much to the right and down. And please, if you think differently, say why. because it tested it (with my code). why are you so angry ? I'm sorry if you got that impression. You come with the inside of the problem which seems unsolvable, instead of explaining what you are actually trying to do, which can be solved by different means. It can get frustrating to try and help. ok, thanks anyway. erez. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd.http://www.lingnu.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: XMoveWindow()
Erez D wrote: On Thu, Mar 4, 2010 at 12:20 PM, Shachar Shemesh shac...@shemesh.biz mailto:shac...@shemesh.biz wrote: Erez D wrote: On Wed, Mar 3, 2010 at 5:05 PM, Shachar Shemesh shac...@shemesh.biz mailto:shac...@shemesh.biz wrote: Erez D wrote: when i write a program, i expect to get the same behaviour which doesn't depend on the WM. however: Traditional window managers reparent the window, and add the titlebar to the parent. compize on the other hand doesn't reparent the window, so the behaviour is different. Yes, but that's avoiding Nadav's question, which was - why is this something for the program to do? i have two displays i want one to be a copy of the other, so when i move a window on one display, i want it to move to the same position in the other. Then it seems to me that you are trying to move the wrong window. Why not run XMoveWindow not on the window you opened, but walk up the parents until you reach the window whose parent is root, and move that one? if i put the parent at x,y - it will place it at x,y. but that not what i want. if i put my original toplevel at x,y - i would expect it to be placed at x,y. but no, it places it's parent at x,y, which means it is placed in an offset. the bottom line: it doesn't matter if i put my window at x,y or it's parent (that belongs to the WM) at x,y - i get the same result. which is not the result i want. That depends on what is the x,y you start with. If you start with the x,y of the top window, and set it for the other top window, then you do get exactly what you want. btw. if i use compiz - it doesn't have a parent. anyway, an app doesn't need to play it differently if it have or doesn't have a WM, or to be dependant on which WM it has. I think the algorithm I gave should work regardless of which WM, but I haven't checked it. And please, if you think differently, say why. because it tested it (with my code). with reparented windows? Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: XMoveWindow()
On Thu, Mar 04, 2010, Oleg Goldshmidt wrote about Re: XMoveWindow(): i have two displays i want one to be a copy of the other, so when i move a window on one display, i want it to move to the same position in the other. ... If you want to allow different WMs on the two screens I doubt it can work the way I understand your requirements This is a very good point. If the two displays have a different window manager, they can also have different title heights, border width, and so on, and at which point it isn't clear why you are convinced that you want to position the top-left corner of the client window on the same x,y position on both, rather than position the top-left corner of the parent (border) on the same position. Both sound logical to some degree, so why not try doing the second (as Shachar explained)? It's at least worth a try. The Window Manager might still dislike what you're doing (after all, it's *its* job to move around windows, not any arbitrary client should do such things), but I believe it should work. Nadav. -- Nadav Har'El| Thursday, Mar 4 2010, 18 Adar 5770 n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |Welcome to the Church of the Holy http://nadav.harel.org.il |Cabbage. Lettuce pray... ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
