-
Notifications
You must be signed in to change notification settings - Fork 3
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
Adjust window box for GTK HeaderBar #2
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! This is really helpful!!!
Since in Linux there are a tone of Desktop / Window managers and GUI platforms and so on, I would suggest to also check if _getGtkFrameExtents()
is not empty nor None and has a length of at least 4, then returning the values retrieved by get_geometry() / translate_coords()
otherwise... Do you agree?
Thank you again!
Yes makes sense, I'll make the change tomorrow. |
I deleted my previous message (I'm a total nerd!). The typing checks failed, so we should fix the code before merging it (do you have access to the checks results? Otherwise, just let me know to send them to you). In addition to that, the PR to PyWinCtl must also be modified in the same way that PyWinBox's one, right? I will also modify the PyWinCtl's setup.py file in order to sync both versions (PyWinCtl will require this new PyWinBox version in order to properly work) |
Yes, I can fix the typing issue. I'll get to it later today. I'll comment in the other PR regarding the PyWinCtl change. |
I guess the same change should be made in set window size as well? I.e., for NET_EXTENTS remove the extents, for GTK_EXTENTS add the extents. Then the window wouldn't resize anymore? There's a similar discussion here
I think this library would be most useful if it would give consistent window size and client frame sizes across platforms and window types. I agree, other window managers and distributions are a concern, but maybe start by getting the most common Linux one right? |
I pushed two new commits. With these, both the moveTo and resizeTo works correctly for both types of windows. I agree its a mess, but I think there might be no good solution here. 😕 |
Hi again! Really thanks a lot for your help and your patience and these kind of discussions which really help a lot!!! I remember to read that article when looking for calculating the client area! To be honest, I then thought that GNOME values were complex and useless! HAHAHAHA! Well, I have made some additional tests in Mint/Cinnamon and Kubuntu. The results using extents in calculations are definitely wrong. Apart from returned values, when visually checking the window position, old versions were right, but not the new version. Check this in KUbuntu:
And this in Mint/Cinnamon (don't know why the "print" statements inside the module do not show in the console output):
In short, it seems that, even though we may agree that we should try to stick to the actual window edges (again, not sure how this is going to affect other users / needs); it has to be done only in GNOME by the moment. |
Do you still get NET and / or GTK extents on these? I have no setup other than Ubuntu GNOME right now ready to test myself unfortunately. I might try to install other window managers to check it out myself, but I'm not sure if I have time for that at the moment. Feel free to commit to this PR, if you want to make changes for the other window managers. I hope it's just the window manager affecting this, not the distribution. |
Yes, but only _NET_EXTENTS in the cases I tested, which returns [0, 0, 27, 0] for almost all windows, and [0, 0, 24, 0] for the LibreOffice splash tips window. The values returned are the ones you have to substract to window position and size if you want to calculate client area only. I mean, these are the values INSIDE the window (mainly title bar height, borders size and/or status bar height, if any... 27 and 24 stand for title bar height), whilst in GNOME (GTK) you get the values AROUND the window. In GNOME, almost all windows return _GTK_EXTENTS = [26, 26, 23, 29] (None for _NET_EXTENTS), but in the case of LibreOffice, it returns _NET_EXTENTS = [0, 0, 37, 0] (and None for GTK value), which again matches a title bar height of 37... It seems that:
We can use this rule to decide how to make all calculations, but I am not sure how this all will work in other distros or combinations. In my opinion, asking if we are in GNOME and if we have _GTK_EXTENTS values before adding/substracting anything is a safer solution... What do you think? Finally, do not worry, I can test anything you need. |
Hi! Sorry to bother you. Are you planning to create a new PR including what we discussed? Just checking, no hurries, of course. It's just to know. If you intend to do so, I will wait. |
I'll be a bit busy until mid of November unfortunately. Then I could have another look at this. |
Ok. Thank you and good luck in your "businesses"! |
Goes hand-in-hand with Kalmat/PyWinCtl#79
This is another attempt at fixing Kalmat/PyWinCtl#66, which still seems to be off for me.
The idea is to get the right box including the title bar / header bar in PyWinBox.
To get the correct client area (i.e., without title bar), the opposite has to be done for HeaderBar-free applications. This is done in a separate PR in PyWinCtl.
So to summarize the state after these two PRs:
For applications without GTK HeaderBar
For applications with GTK HeaderBar
This would handle 3 of 4 cases perfectly, only getClientFrame with GTK HeaderBar still doesn't work. But it would still give a reasonable result in that case.
The test might need some more work (failed for me on master as well though). Let me know if you want me to take a stab at it. Otherwise feel free to just add to this PR.