Miscellaneous path configuration issues

[Versatilus]

The path to the Python interpreter used to run asynchronous commands such as the custom MouseGrid windows and settings window has been determined by a variable stored in the main configuration file. The past default value was manually set to the stereotypically default Python installation path. This resulted in a failure, usually silently, of these asynchronous commands if the user used a different path for their Python installation.

My solution for this problem uses both the sys and sysconfig modules to build a database of relevant system information, one which can be easily expand upon in the future. Using this information, the default value of that variable is automatically set to the location of the installed PythonW executable.

It was around this time that we noticed that the purpose of the variable pointing to the current wxPython distribution was an effort to get around a weird installation issue. This is more appropriately fixed by upgrading the installed version of wxPython. The configuration variable was removed and an appropriate error message was added to the settings window script, which was the only section of code that uses wxPython.

In the process of fixing this issue a generic message directing users to places they can get help was added to the settings module for future use.

Addressing these issues resulted in the following commits:

• Automatically detect pythonw.exe path if available.
• Minor changes to improve future Python 3 compatibility.
• Added a generic help message for use in error messages.
• Require the latest version of wxPython if the module import fails
  instead of using a configuration variable to work around an old wxPython
  installation issue.

[LexiconCode]

Regarding PYTHONW in the settings. Should the path PYTHONW = "C:\\Python27\\pythonw.exe" be PYTHONW = "C:/Python27/pythonw.exe"?

replace( "\\", "/")

[Versatilus]

As best as I can tell, they should really all be done with backslashes instead of forward slashes. I believe the reason it was done this way is because escaping the backslash character in sequences is easier for people and using the forward slash character generally works most of the time. Because everything else in the Windows ecosystem expects the directory separator character to be the backslash, it can cause issues when interacting with system functions.

I've been thinking lately that it would be a good idea to at least transparently pass paths to Windows in the expected form. This can easily be done using Python's os.path.normpath() function.

[Versatilus]

If no one has any objections, I'll be merging this in the morning (15:00-19:00 GMT Thursday).

[mrob95]

That same line exists in quite a few places, I think I changed them all in #336
synkarius@c51d7f5

[Versatilus]

I'll look that over in a few hours before I decide what to do with this. I got distracted this week and I never got back to it.

[LexiconCode]

Can we update pull request to prep for merge?

[kendonB]

I have updated this PR with the latest state of the repo. It might be worth one final review from @Versatilus or @LexiconCode

[LexiconCode]

I will get this tested and merged Monday! Thanks for bringing it up-to-date!

[LexiconCode]

Works as expected. @kendonB

As best as I can tell, they should really all be done with backslashes instead of forward slashes. I believe the reason it was done this way is because escaping the backslash character in sequences is easier for people and using the forward slash character generally works most of the time. Because everything else in the Windows ecosystem expects the directory separator character to be the backslash, it can cause issues when interacting with system functions.

I've been thinking lately that it would be a good idea to at least transparently pass paths to Windows in the expected form. This can easily be done using Python's os.path.normpath() function.

However normalizing paths using os.path.normpath() needs to be implemented in a separate pull request.