Skip to content
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

get the windowHandle from window, #119

Merged
merged 4 commits into from
Jan 18, 2021

Conversation

nebukadhezer
Copy link

in a wrapped context windowHandle can return None

@@ -1071,7 +1071,7 @@ def heads_up(self, title, message, command=None):
def paintEvent(self, event):
if Qt.__qt_version__.startswith("5") and os.name == "nt":
# Only tested with Windows DPI scaling
scale = self.windowHandle().screen().logicalDotsPerInch() / 96.0
scale = self.window().windowHandle().screen().logicalDotsPerInch() / 96.0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eeeek! There were already too many things that could go wrong with this line, could we break this up and handle each one separately? Especially if window is None: and if window_handle is None and if screen is None.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the PR, as in the issue... there also would be widget.nativeParentWidget() but the method potentially returns 0...
I asked in the PySide gitter channel but there was not much response. I am using widget.window() in many places and at least in my constructs it always gets the correct topLevelWidget I want.
As I said I dont know in which scenario the window method would not return a native widget...

nebukadhezer and others added 2 commits January 11, 2021 10:56
@mottosso
Copy link
Member

I've made some tweaks to the error handling of this, to ensure that it works if it works, and tells you exactly why it doesn't work without breaking the functionality of the tool. I didn't actually test this however, so do see whether it works for you.

@nebukadhezer
Copy link
Author

Hey Marcus!
image
looks good!

@mottosso
Copy link
Member

Does it though? xD Hard to say to be honest, sizes are all over the place.

  1. The top toolbar looks too small in both versons
  2. The padding around the bottom buttons looks OK on the right
  3. The size of the bottom buttons are too large on the left

The only thing that looks consistent overall is the middle listing. Is this what it looks like unscaled as well? :O They should ideally look identical, apart from pixel density.

@nebukadhezer
Copy link
Author

Sigh, you are right, this does not look identical and "good" is my opinion, to my defense I thought the delegate fix was only for the section that uses delegates, which in my head is only the middle part (I might be wrong here). I am just happy that I can actually use the interface again. And dont have to look at shredded lines...
That being said I totally understand that this probably could be and should be consistent. I have to dig a bit deeper to find the cause for this... Just to get back to the scope of the ticket/pr, this is a fix for the failing code, when pyblishlite is not a native window. I did not write the delegate scaling fix in the first place. And the this fix is certainly not responsible for the different scales of the top and bottom bar. It only makes it work when pyblish lite is not a native window.

@mottosso
Copy link
Member

And the this fix is certainly not responsible for the different scales of the top and bottom bar.

Aha, that was the part I wasn't sure about. Ok, in that case it must have happened earlier.

Let's merge this. Thanks @nebukadhezer!

@mottosso mottosso merged commit f0db29d into pyblish:master Jan 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants