-
Notifications
You must be signed in to change notification settings - Fork 778
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistency in window frame offsetting #1341
Comments
[Original comment by lolilolicon@…] Ah, forgot to mention that my mpv windows all float! |
[Original comment by lolilolicon@…] A related / interesting thing about the title bar: if you run
The |
[Original comment by lolilolicon@…] Interestingly, if I click on the left-top window title bar, I get the same window 0x400045 and the exact same output from |
Replying to comment 3 by lolilolicon@…:
That’s because you’re clicking into the split container, onto which the window decorations are rendered. Your comment 2 and 3 are all working as intended. |
Replying to #1341 by lolilolicon@…:
Hm. I’m open to convincing here, but I cannot find clear documentation on how window managers should interpret the geometry it gets from actual application window. The closest thing I can find is the X11 protocol documentation, which states:
So, based on that, i3 is behaving correct with regards to the title bar (but incorrect with regards to the left/right/bottom? borders). I’m more interested in what toolkits assume, though. Could you come up with sample applications in GTK and Qt that store their geometry and try to restore it on startup? |
[Original comment by lolilolicon@…] Replying to comment 4 @…:
I guess that's understandable, but it's a bit counter-intuitive, isn't it? Replying to comment 5 @…:
The documentation in your quote is about
Nope, I'm not familiar with that kind of behavior. But I think it's enough to use sxiv as an example. Here's basically how sxiv opens its window (
For the purpose of this bug, let's ignore the I think the question here, is when an application requests the upper-left outer corner of its window to be put at This also begs for a clear definition what the "frame window" is in i3. Currently it seems to be the visible frame excluding the title bar, which is counter-intuitive. Related documentation: The X11 protocol documentation says,
The "Window Geometry" section in the EWMH spec includes some clarification
|
Replying to comment 6 by lolilolicon@…:
I don’t think the actual application should ever be interested in the height of the title bar.
The CreateWindow documentation is not any more helpful unfortunately:
I don’t think it’s enough. Having these examples with the two most popular toolkits would make for a much more convincing case.
I agree with the question, but I’m still not sure about which possibility is correct.
i3 doesn’t really use frame windows in the conventional sense.
That’s a good bit of information, but I don’t find it very clear :|. I.e., does it mean that when I request a 200x300 px window at (0, 0), should the window manager assume that 200x300 px is widthxheight including the borders? In that case, how would an application open a window that has at least 200x300 px? It cannot know the border width/height beforehand. (In general we want applications to not care about window sizes and just scale, but that’s not the point here.) Perhaps you could send an email request for clarification on the wm-spec mailing list where these standards are discussed? |
[Original comment by lolilolicon@…] Replying to comment 7 @…:
OK, Gimp is a very good example. BUT there is a slim window in which i3 will force center the Toolbox window when Gimp is restarted. You can reproduce this by moving the Toolbox window so that some but not all of its title bar is off-screen, then restart Gimp.
In i3, the So are you convinced we have a bug here now? |
[Original comment by lolilolicon@…] I just want to add that, considering i3's support for tab and cascade layouts for tiled windows, it makes sense the title bar is ignored. So I understand that if anything shall be done to fix this bug for floating windows, the code probably will need to make a special case for floating windows, which is not something anyone wants to do to their own code. At least we have had some discussion here; whatever is to be done is up to you developers' choice :) |
(not a full answer, but interesting excerpt from #xcb with psychon (awesome)):
|
[Original comment by lolilolicon@…] Replying to comment 10 @…:
We all agree that the size of the client window should just be as requested by the client. This following quote from the EWMH spec,
its use of the word "size" and general phrasing makes it somewhat confusing. I think what it means by "size" is all of the client window's geometry parameters: At initial placement, the window manager "takes the initial window's size into consideration", i.e. uses the client window's geometry parameters, to calculate the reference point:
Do you agree with this interpretation? |
@stapelberg I'm a bit lost with the discussion here, but it's a year old now. Is there anything we plan on doing? |
I think it would be nice if the problem was addressed, provided it can be addressed without a big amount of complexity (given that we’re talking about floating windows here). From my reading of the discussion, I think the summary is “i3 places windows somewhere else than where users expect when they start applications with geometries like +0+0”. |
This allows the floating container's top left corner to be mapped outside any output as long as they are contained partially by one. This, for example, will allow: mpv --geometry +1+1 video.mp4 For windows mapped to (0, 0) see comment in floating.c:270-273: /* Some clients (like GIMP’s color picker window) get mapped * to (0, 0), so we push them to a reasonable position * (centered over their leader) */ The floating_reassign_ws call is removed since we try to place the new floating container in the current output: /* Sanity check: Are the coordinates on the appropriate output? If not, we * need to change them */ Fixes i3#1341
This allows the floating container's top left corner to be mapped outside any output as long as they are contained partially by one. This, for example, will allow: mpv --geometry +1+1 video.mp4 For windows mapped to (0, 0) see comment in floating.c:270-273: /* Some clients (like GIMP’s color picker window) get mapped * to (0, 0), so we push them to a reasonable position * (centered over their leader) */ The floating_reassign_ws call is removed since we try to place the new floating container in the current output: /* Sanity check: Are the coordinates on the appropriate output? If not, we * need to change them */ Fixes i3#1341
Please file a new bug with steps to reproduce instead of posting on many-year old bugs. |
I opened a new bug report at #5953 with steps to reproduce. |
[Originally reported by lolilolicon@…]
(I notice the window frame in i3 is handled inconsistently between the left frame and the top (title bar) frame. For example, in my case, the title bar is 20 pixels in height, so if I run
mpv --geometry +0+20 video.mkv
, the window frame is placed with its left-top corner at(0, 0)
; this is because i3 automatically shifts the mpv window 2 pixels (the size of the left frame/border) to the right, but does not automatically shift the mpv window down in the same manner. This results in unexpectedly thatmpv --geometry +0+11
will make i3 put the mpv window at the center of the screen, presumably because i3 calculates that the left-top corner of the frame would be at(0, -9)
and decides to resort to putting it at the center of the screen.The discussion above ignores the fact that the win_gravity of the mpv window is actually
CenterGravity
, notNorthWestGravity
, which I think may change the expected resulting frame coordinates. (To be tested in Mutter when I get the chance).The text was updated successfully, but these errors were encountered: