Fix QFontMetrics.width deprecation warning

[aaronayres35]

fixes #653

This PR simply uses QFontMetrics().horizontalAdvance() instead of QFontMetrics().width()when possible (horizontalAdvance was introduced in Qt 5.11) to avoid a deprecation warning.

Same fix was done in an open PR on traitsui: enthought/traitsui#1315

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@48c54cc). Click here to learn what that means.
The diff coverage is 95.45%.

@@            Coverage Diff            @@
##             master     #715   +/-   ##
=========================================
  Coverage          ?   40.54%           
=========================================
  Files             ?      502           
  Lines             ?    27660           
  Branches          ?     4197           
=========================================
  Hits              ?    11215           
  Misses            ?    15973           
  Partials          ?      472           

Impacted Files	Coverage Δ
pyface/util/testing.py	88.57% <ø> (ø)
pyface/__init__.py	88.88% <90.00%> (ø)
pyface/ui/qt4/code_editor/code_widget.py	44.39% <100.00%> (ø)
pyface/ui/qt4/code_editor/find_widget.py	100.00% <100.00%> (ø)
pyface/ui/qt4/code_editor/gutters.py	52.38% <100.00%> (ø)
pyface/ui/qt4/code_editor/replace_widget.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 48c54cc...2e1b45b. Read the comment docs.

[kitchoi]

All the changes are pretty similar and they solve the same compatibility problem. Could we refactor the handling font_metrics.width(" ") into a single function?

I am wondering if it is worth having a module for compatibility among various versions of Qt, so that when we drop a specific version of Qt, we can maintain the compatibility layer more easily. @corranwebster, what do you think?

(I would have wanted to designate such a module to be private to pyface to start with, but I don't think there is a notion of private modules in pyface so far 🤷 .)

[corranwebster]

@Kit we already do some amount of fix-ups to make the APIs match (mainly imports between Qt4 and Qt5) in the pyface.qt code, so we could, potentially, do something like monkeypatching old versions of QFontMetrics to add horizontalAdvance as a synonym for width.

[kitchoi]

Hmmm the pyface.qt package only normalizes the API namespace differences among different Python/Qt wrapper without changing behaviour. When I import from pyface.qt, I consider it being a collection of aliases and I trust what I use from there to be consistent with what I get if I had imported the objects from PySide2 and PyQt5 directly. Modifying behaviour and monkeypatching will absolutely kill that assumption and understanding for that package.

[kitchoi]

I was mainly thinking about defining and reusing a function like this which is simple enough and we can find their usage again easily:

def font_horizontal_advance(qfont_metrics, text):
    if QtCore.__version_info__ >= (5, 11):  # as in this PR
        return qfont_metrics.horizontal_advance(text)
    return qfont_metrics.width(text)

If adding this function is okay, the question is, where should this live?
Ideas: pyface.ui.qt4.compat?

[kitchoi]

On the other hand, these repetitions are still minor so I'd also be happy to just merge this as it is.

[corranwebster]

I think it's fine to merge as-is myself. If we were to generalize/unify as a separate function, I think it would make sense to do so to Wx as well (similar to what we do with ISystemMetrics for screen size).

[corranwebster]

I have opened #716 to remind us of the discussion.

[kitchoi]

SGTM.

[rahulporuri]

Can we create an issue and link it in the changes being made in this PR? I don't want future us arriving at these pieces of code after a random walk through the pyface codebase.