Make sure loadUi is available

[astrofrog]

Glue makes use of loadUi extensively, and there are a number of available patches going around to provide this in PySide. This PR adds such a patch (adapted from qt-helpers, which itself came from a previous solution).

This works fine, but one thing that all solutions seem to require is that for PySide, custom widgets need to be explicitly specified. However, this is not ideal because it provides an API that is not consistent with PyQt4/5 (where the custom widgets are auto-loaded).

One solution would be to parse the XML ourselves and load the custom widgets specified in the ui files (since the ui files provide the path to import the class). I can implement this, but I wanted to check first whether there are any objections to this?

As for #25, I included copies of the licenses for the adapted code, but there might be a better way to do this (for example we could include this in LICENSE, or have a separate file describing where various parts of the code were taken from and what their licenses were?)

Closes #16

cc @Nodd

[ccordoba12]

@Nodd, could you review this one please?

[goanpeca]

@astrofrog I disabled the complaint on non pythonic names (which is not good advice when working with Qt)

But the other suggestions are valid:

1. Consider documenting your class(es)Disable
   1 issue in 1 file.
2. Consider documenting your function(s)
   1 issue in 1 file.

[astrofrog]

@goanpeca @ccordoba12 - I've added fixes, but I think in this case the coding guidelines are being over-strict. The class that was missing a docstring was private (starting with _) and the function that was missing a docstring was a test.

[goanpeca]

@astrofrog yes probably, but even if private a docstring is always a good idea :-p. For the test one, yes I agree it is kinda too much, but thanks for including the changes 👍

[Nodd]

Use the constants here: PYQT5 and so on

[astrofrog]

Fixed

[Nodd]

The logic in createWidget is a bit different from python_qt_binding (https://github.com/ros-visualization/python_qt_binding/blob/kinetic-devel/src/python_qt_binding/binding_helper.py#L195). From what I understood it' calling QUiLoader.createWidget in more cases, but I don't know if it matters in practice.

@astrofrog Regarding PySide, has any other project tried to load the custom classes from the xml directly ?
The feature is very interesting, but for now I think it's better to mark the failing test as xfail if Pyside is used, and eventually fix it in another PR.
python_qt_binding has the following comment:

        # instead of passing the custom widgets, they should be registered using QUiLoader.registerCustomWidget(),
        # but this does not work in PySide 1.0.6: it simply segfaults...
        #loader = CustomUiLoader(baseinstance)
        #custom_widgets = custom_widgets or {}
        #for custom_widget in custom_widgets.values():
        #    loader.registerCustomWidget(custom_widget)

Can it be useful with a newer version of PySide ?

[Nodd]

If self.customWidgets is set to an empty dict if None (in the constructor), you would only catch KeyError here. It would be easier to understand.

[astrofrog]

Fixed

[astrofrog]

Can it be useful with a newer version of PySide ?

Yes but we'd still need to get the custom widgets from the XML, which I think should be reasonably easy. However, I can indeed do it in a separate PR.

[Nodd]

@goanpeca Can you disable "Avoid using "non-Pythonic" variable names" in QuantifiedCode, please ?

[ccordoba12]

Please remove these lines as part of this PR:

https://github.com/spyder-ide/qtpy/blob/master/qtpy/__init__.py#L83

https://github.com/spyder-ide/qtpy/blob/master/qtpy/__init__.py#L103

[ccordoba12]

However, I can indeed do it in a separate PR.

Yep, please leave it for another PR.

[astrofrog]

@ccordoba12 - done!

[ccordoba12]

@Nodd, please merge this one when you consider is ready.

[Nodd]

If it's only needed for testing, the class can be defined in test_uic.py, to leave uic.py clean.

[astrofrog]

The issue is that it needs to be part of an importable module. I could create a fake module for the duration of the test though, so I can investigate that.

[Nodd]

The test file itself is importable, isn't it sufficient ?
Otherwise I think that having a separate file in the test directory containing the class is fine. Your workaround works but seems needlessly complex to me.

[astrofrog]

I tried having a file in the tests directory, but this causes issues in Python 2, because it seems that when I adjust sys.path, the class I import from the tests appears to be different from the one that PyQt4/5 imports. I tried working around that, but in the end, the solution in this PR is the cleanest (even though it may look complex).

[astrofrog]

By the way, the reason I have to mess with sys.path and why this is complicated is because the tests need to also be runnable from outside the tests directory, so I want to be able to do py.test tests/ for instance.

[astrofrog]

Here's an example of the type of error I get if I try the approach you are suggesting:

>       assert isinstance(ui.comboBox, _QComboBoxSubclass)
E       assert isinstance(<test_uic._QComboBoxSubclass object at 0x11882f5e8>, _QComboBoxSubclass)
E        +  where <test_uic._QComboBoxSubclass object at 0x11882f5e8> = <PyQt5.QtWidgets.QWidget object at 0x11882de58>.comboBox

somehow it seems to think there are two different _QComboBoxSubclass classes.

[Nodd]

Sorry for the last-minute nitpick, otherwise it's ready to go !

[astrofrog]

@Nodd - I think this is good to go - I know the solution here seems a little strange, but see my replies to your comments above: I can't figure out a way to get this to work if the subclass lives in the test file.

[Nodd]

It's OK, there are problems in python if the same module is imported from 2 different paths. Thank you for your work !