Daniel,
The check is in...
wxPython-src-3.0.2.0/wxPython/src/osx_cocoa/_core.py
# make sure we can create a GUI
if not self.IsDisplayAvailable():
if wx.Platform == "__WXMAC__":
msg = """This program needs access to the screen.
Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac."""
elif wx.Platform == "__WXGTK__":
msg ="Unable to access the X Display, is $DISPLAY set properly?"
else:
msg = "Unable to create GUI"
# TODO: more description is needed for wxMSW...
raise SystemExit(msg)
It must be a valid warning because of the preceding check on " if not
self.IsDisplayAvailable():".
Jack
ps I've attached the test packaging I am using for wxpython300-py.
On Fri, Jan 30, 2015 at 8:48 PM, Daniel Johnson
<dan...@daniel-johnson.org> wrote:
>
>> On Jan 30, 2015, at 8:15 PM, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>>
>> Daniel,
>> While working on a new wxpython300-py package to support the
>> newest release of relax 3.3.5 (which considers wxwidgets prior to 3.0
>> to be too buggy), I discovered that two major problems. The cocoa
>> variant of wxpython300-py was easy to build against
>> wxwidgets300-osxcocoa, however when a relax-3.3.5 was built against it
>> and run with 'relax --gui', the wxpython300-py code produces a fatal
>> error saying that the cocoa support requires a framework build of
>> python to run. The gtk2 variant of wxpython300-py is even more
>> problematic as upstream no longer supports OS X/gtk2. After hacking
>> the configure to retrieve that build option, it became apparent that
>> the OS X/gtk2 code base has bit-rotted and will require a major effort
>> to restore it.
>> Thus if we want to have a functional wxpython300-py which is
>> supported upstream, we will have to transition the python packages to
>> a framework build. Hopefully we could implement some carefully placed
>> symlinks to ease the transition.
>> Jack
>
> That shouldn't have anything to do with whether it's a framework build. A
> framework is just an alternate way to package a library. There is no
> difference between a shared library build and a framework build other than
> where the files are installed.
>
> More likely it's because our pythons link to our tcltk which is X11-based
> instead of cocoa-based. So either we would need to change tcltk to a cocoa
> build or link to the system's tcltk which does. Python uses tcltk to build
> its tkinter module, which is used to build GUIs. Either way is going to break
> things. Anything using pygtk will certainly break and I know pil-py also uses
> tkinter. I'm not sure what the solution would be.
>
> Daniel
>
wxpython300-py.info
Description: Binary data
------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
