So this basically undoes#8144, but that's supposedly fixing a bug. Is there some difference in Qt5 versions being used or something?

This is what I am using when seeing the bug:

(test) efiring@manini2:~/currents/programs/pycurrents/scripts$ conda list pyqt# packages in environment at /Users/efiring/anaconda/envs/test:#pyqt                      5.6.0                    py35_0

What about qt?

@QuLogic Ithink the bug was in@astrofrog 's example code. Internally we need to use the the pixels the renderer thinks it has not the pixels qt thinks it has.

attn@astrofrog Can you test this out with both qt5 and osx?

I still suspect that there are a bunch of un-needed scaling factors in there (as we scale up one place and down in the other), but it is not clear exactlywhich pairs of them need to be pulled out.

And I am working on a "high-dpi" style sheet.

@tacaswell - can you mark me as a reviewer so that I don't lose track of this, and I'll review/test it on Monday

I deleted a comment about this hanging my terminal; it seems to have been caused by an ipython version update.

@tacaswell, your suggestion of adding back the block that was deleted at the end ofcedaaae works fine; I think that with that change, this is ready for 2.0.1.

Sorry I dropped the ball on reviewing this, I won't have time to check it in the short term but I don't want to delay 2.0.1, so this is fine by me.

@efiring Can you test this set of commits (I force-pushed).

There is one more thing I want to add (but might not be worth holding PR over) is to connect up the signal Qt provides when the dpi ratio changes.

In my quick check, it looks good and works perfectly. I tested saving to png via the gui, manual resizing, get_size_inches and set_size_inches, cursor readout, and zoom to rect.