freenode/#clim - IRC Chatlog
Search
5:56:56
loke
jackdaniel: I figured out what's going on, but I haven't written any test code yet. IIt became clear to me as I was lying in bed last night thinking about how this stuff actually works.
5:57:16
loke
jackdaniel: I'll just summarise it here, since I know you normally read up on the backlog here :-)
5:58:56
loke
jackdaniel: What happens is that you are getting a window reconfigure event that contains the X/Y coordinates. These are the coordinates with respect to the parent window. The parent windiw is typically the one owned by the window maanger, which means that its coordinates are relative to the decorated window.
6:00:38
loke
What seems to happen is that most window managers will move the actual window down a bit to compensate for the size of the decorations. When you add the X/Y coordinates from the reconfuigure event, you effectivelly calcualte the origin position of the decoration window.
6:01:45
loke
However... and here's the first problem: Not all window manemanagers do this. That explains why I've had menys being _slightly_ off when using StumpWM's Floating windows. (the floating windows behaves like a normal window manager, with decorations, but it never performs the adjustment by moving the actual window like most WM's do)
6:02:53
loke
The X-serevr in which the CLIM application runs does not have a window manager. Therefore, when you get a reconfigure event, the X/Y coordinates are with respect to its parent window, which is the Root Window
6:03:20
loke
Also, there is no adjustment, of course, which is why the application thinks that its coordinate is 2× the actual position.
6:04:20
loke
I believe you'd also be able to reproduce it using the “twm” window manager, because I don't think it moves windows the same way.
6:05:41
loke
Finally, I'm not sure trying to find the origin of a window+decorations is the right thing to do. There isn't even any guarantee that the decorations will be contained in a single window, and I don't believe there is anything in the X spec to suggest it should be.
6:06:06
loke
jackdaniel: I'm going to lunch now, so I'm just leaving this here to let you and perhaps other digest it.
11:08:32
jackdaniel
I don't have travelling window problem when I'm using terminal, emacs, browser etc and I take that they work just fine on Qubes and on StumpWM
11:12:54
loke
jackdaniel: I can't explain that at the moment, since I have been able to reproduce the travelling window problem (which, in turn, is because I haven't yet tried :-) )
11:13:56
loke
That said, what I can tell you is that application sgenerally cannot expect to know where a specific window is going to end up. It is only possible to request a location where it's wanted, and then hope that it will end up somewhere in the vicinity
11:14:15
loke
Twm, for example, completely ignores the request from the application and asks the user where to place it
11:15:07
loke
In other words, once cannot, typically, expect to be abel to do things like "move the window X pixels in direction D". Well, you can, but to do so you must use OverrideRedirect.
11:15:52
jackdaniel
how about: don't move window, but resize it to requested width/height *without* moving the top-left corner of it
11:17:24
loke
jackdaniel: I have to leave the office now, but I will write some test code (standalone Xlib program) that performs such resizing
11:17:44
loke
Hopefulyl such program will be helpful to demonstrate how to do these things on a lower level.
11:20:34
jackdaniel
sharing is good ;-) but I can't promise I'll work on that since I'm occupied with patterns
11:21:12
loke
jackdaniel: That's fine. I'll work on it as best as I can, but you know about the potential issues, so I need to check with you every step :-)
11:30:47
jackdaniel
computers are amazing. I've noticed that something broke scrolling. I've resetted last commit and it worked back. I've brought that commit back and recompiled files - it still worked