Closed roym899 closed 11 months ago
Hi! We should include the changes introduced in PyWinBox's PR into this PR too. I mean, taking into account GTK frame extents as well, right?
I think this should be fine as it is. Basically with the GTK HeaderBar we don't have a way of getting the client frame right now. The GTK frame extents seems to be only the shadow around the window, not the extents of the header bar. That's why I'm subtracting them in PyWinBox.
So right now the state is if we have net_extents: PyWinBox increases the box by the net extents, because the default
geom = handle.xWindow.get_geometry()
pos = handle.root.translate_coords(handle.id, 0, 0)
is only returning the client frame), getClientFrame removes the net extents again (to get the correct client frame)
if we have gtk_extents: PyWinBox removes the gtk extents (because the default includes the shadows, which size is given by the gtk extents), getClientFrames just returns the result from PyWinBox (since there's no (?) way of knowing the size of the header bar)
if we have neither: getClientFrame just returns the result from PyWinBox (based on the code snippet above)
Maybe add a warning in the latter two cases, that getClientFrame is not supported for this type of window and that the original window size is returned?
I don't agree with this. When we have NET_EXTENTS (this is the size of the titlebar) they should be subtracted in getClientFrame() assuming the window box from PyWinBox is correct and includes the titlebar.
Hi!
I don't fully understand, sorry. I am not sure if you don't agree with my reply or you are proposing to use _NET_EXTENTS to add/subtract these values in getClientArea() in order to calculate the right area. If this last is the case, it is exactly what I was proposing. Sorry for confusing you. Let me explain myself better.
If we have _GTK_EXTENTS (this happens only in GNOME), we will not have _NET_EXTENTS (at least as far as I have tested). So, if we have _GTK_EXTENTS, and those values have been already added / subtracted (added to X, Y coordinates, subtracted from WIDTH and HEIGHT) in PyWinBox; and also given the fact that I didn't find a way to get the title bar height (or other interesting values like borders or status bar and so on), I can not add / subtract anything to find the right client frame, so we should return the box returned by PyWinBox (which includes title bar and all other stuff... not ideal, but I have no other solution at the moment).
If we don't have _GTK_EXTENTS, we will likely have _NET_EXTENTS, so these values must be added / subtracted to find the right client area, since they shouldn't be added/subtracted in PyWinBox, and in this case we already have the additional values that allow us to properly calculate the client area.
So, the result of all of this should be something like:
PyWinBox (_getWindowBox):
PyWinCtl (getClientFrame):
Sorry, I misunderstood you. Yes, I agree in that case.
I guess that means this PR can stay as it is?
Only part I disagree with is this: PyWinBox "Otherwise, do not add/subtract anything": at least in GNOME when I tested, we'd have to correct the box (by adding NET_EXTENTS), since it does not correctly include the title bar otherwise. (which in turn would result in a wrong client box in here)
I think this PR should stay as it is, however, the PyWinBox PR should be adjusted to account for other window managers if possible.
Just to be sure we are on the same page: "Otherwise" in my reply means we are NOT in GNOME and/or we do NOT have _GTK_EXTENTS (some apps like LibreOffice or Firefox do not set it). Again, I think we are proposing the same!
Goes hand-in-hand with https://github.com/Kalmat/PyWinBox/pull/2
This fixes getClientFrame for GTK HeaderBar-free applications.
There is still no way (?) to get the ClientArea for applications with GTK HeaderBar. But at least we're getting the tight bounding box around the window now.
See the other PR for more description.