Kazunobu Kuriyama wrote:What I saw was this: every window of GNUstep apps were shifed upward about
Alexander Malmberg wrote: <snip>
I tried this patch and found that the windows of GNUstep apps appear slightly higher than before. I have little time to track it down now, so I don't know the reason exactly.
Is this a one-time thing, or a gradual shift? If it's just a one-time offset, I wouldn't worry about it. The old code was a bit off, and this would mess up the coordinates of events at times. Thus, I'm not surprised that there's a slight shift to bring everything in line, although I'm not entirely sure what the direct cause is.
15 to 20 pixels (just about the width of title bars) after applying the patch.
The shift was persistent: even after I had dragged a window, expecting NSUserDefault
would remember this, the shift was not rectified when I gave an app a next run.
So I thought the patch gave some upward bias to the location of the windows.
Skimming the patch, I feel it should use XQeuryTree() and XGetGeometry() before
+ int root_x, root_y; + Window root_child; + XTranslateCoordinates(dpy, xEvent.xconfigure.window, + RootWindow(dpy, cWin->screen), + 0, 0, + &root_x, &root_y, + &root_child); + x.origin.x = root_x; + x.origin.y = root_y;
to get the window of the parent and its coordinates, and pass them to XTranslateCoordinates() if it does need them, not the ones of the root window.
I don't understand what you're trying to accomplish by doing that. The only thing I can think of is that you want to get the coordinates of the window including decorations added by the window manager. However, those aren't the coordinates we want, and we have no way of getting them since we can't assume that all window managers will use any particular structure of windows (parents, siblings, etc.) for decorations.
Ah..., what I wanted to suggest was this: use the global coordinates system of GNUstep (though I'm not sure if there is it). Because the shift was persistent and constant, I thought it should be related to the coordinates system defined internally by GNUstep. So I thought use of such coordinates, instead of ones of the root window, might fix the problem.
Did you have something else in mind with that change?
Apart from window decorations, I'd like to encourage your investigation on this issue because the current GNUstep's DnD mechanism somehow looks interfering with other non-GNUstep X applications' DnD, too. (I also expect it might fix a strange cursor change problem.) So if I find any problem relevant to the patch, I will definitely report it to the list (with a technical idea if I could). In fact I still use the patched -back to see what happens with it, though it may differ from the purpose you intended.
Regards, - Kazunobu Kuriyama
P.S. I got your reply about 12 hours later after you sent it. Other mails are arriving at me in a quite chaotic order now. So I'm afraid my relply looks as if I ignored the comments of other people. If so, please don't get me wrong.
_______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
