Add Windows Compatibility

[aganders3]

These are mostly simple fixes to just get the GPI framework running on Windows. Some of the changes relate to experiments in getting PyFI and the C-based core nodes (e.g. fftw) working, which seemed to be a dead end.

I think the plan for now is to evaluate these changes and merge the ones that make sense to get a minimal GPI framework version running on Windows. Once that is working we can start building a separate Windows package on conda-forge. For now this package will not include PyFI and multiproc. The next step will be packaging core-nodes-lite with just the pure-Python nodes in core.

I initially did this work over a year ago, so my memory is rusty and there are sure to be some mistakes within.

[borupdaniel]

@aganders3 just wanted to give you a heads up that I'm starting in on this! Now that we're doing noarch packaging, it seems like one route will be to just make the PyFI and multiproc parts conditional on detecting a non-Windows OS — does that seem like a sensible approach to you?

[borupdaniel]

This appears to be working fairly well. I haven't run into any bugs related to multiprocessing at all. Compiling with gpi_make does not work, which is to be expected.

A more important bug is that the pop-up search menu is not clickable. This occurs in both configs I tested for Python/PyQt: 3.8/5.12, and 3.7/5.9.

[borupdaniel]

It looks like what's happening with this bug is that the enterEvent is not being triggered when mousing over the fauxMenu during a search. Seems like it may be related to this thread.

Defining the pop-up search results as a "tool" window seems to cause it not to recognize the cursor entry (deleting the line self.setWindowFlags(QtCore.Qt.Tool | QtCore.Qt.FramelessWindowHint) in lib/gpi/library.py causes the pop-up menu to function properly, but makes it the active window after each character is typed, which is bad).

@grlee77, you made some modifications to the search menu setup in your PyQt5 PR so I'm assuming you have a bit more Qt experience than I do — any ideas for how we might get the fauxMenu to recognize the cursor entry in Windows?

Also pinging @nckz, any thoughts from the initial build of GPI? This may not have been an issue in Qt4.

[borupdaniel]

I also tried setting the WA_Hover property by adding the following line, with no success:

self.setAttribute(QtCore.Qt.WA_Hover,True)

[aganders3]

Thanks - glad you're taking a look at this.

it seems like one route will be to just make the PyFI and multiproc parts conditional on detecting a non-Windows OS — does that seem like a sensible approach to you?

This seems good to me!

This appears to be working fairly well. I haven't run into any bugs related to multiprocessing at all. Compiling with gpi_make does not work, which is to be expected.

This was my experience as well. I eventually had things compiling with gpi_make but they would just segfault anyway. I'm not sure if the work required there is worth it.

A more important bug is that the pop-up search menu is not clickable. This occurs in both configs I tested for Python/PyQt: 3.8/5.12, and 3.7/5.9.

I don't think I can be of much help here. I know we revisited the FauxMenu thing when merging @grlee77's qtpy changes, but I can't remember how that was resolved.

[borupdaniel]

I think I've found a work-around here by using the Qt grabKeyboard and releaseKeyboard functions — this avoids the need to have a "fake" menu altogether. There's a bit of trickiness in how GPI handles edge cases where you type a search, then want to use the regular menu -- in this setup (on Windows, anyway) you have to click back into the main menu.

This was the only major problem I'd identified — open to any other testing if someone has time. I will check out this PR on OSX/Ubuntu tomorrow to make sure it hasn't broken anything there.

[borupdaniel]

The only behavior change this seems to cause is that while using the search, mousing over the main menu now does nothing. Previously, you could have search results present and also navigate the main menus, like so:

Now, mouseover does nothing once something has been typed into the search box. A click closes the search results menu and returns focus to the main menu, and a mouse move or second click is required to trigger menu actions. Keyboard focus remains the same, otherwise.

I'm inclined to just let this be the behavior on all platforms rather than maintaining platform-specific code just to restore the above behavior. Any thoughts on that, @aganders3? I honestly don't know if I've ever used a "search for something, then decide I want to use a different part of the menu" workflow, which is the only time this would be a minor annoyance.

[aganders3]

I'm inclined to just let this be the behavior on all platforms rather than maintaining platform-specific code just to restore the above behavior. Any thoughts on that, @aganders3? I honestly don't know if I've ever used a "search for something, then decide I want to use a different part of the menu" workflow, which is the only time this would be a minor annoyance.

I haven't tested it but this sounds fine to me. You're a heavier GPI user at this point so if you think it's good/better/not worse then I think that's fine. Having the same behavior on all platforms seems like the best idea to me.

[borupdaniel]

You must have read my mind — I was just getting ready to merge this and call it version 1.2.0. I think I've figured out how to take care of the core nodes and install script for windows as well.