bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] ConfigureNotify events


From: Kazunobu Kuriyama
Subject: Re: [patch] ConfigureNotify events
Date: Thu, 04 Mar 2004 00:43:27 +0900
User-agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1

Alexander Malmberg wrote:

Kazunobu Kuriyama wrote:

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.

What I saw was this: every window of GNUstep apps were shifed upward about
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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]