Open eneftci opened 12 years ago
Yes I noticed that too.. Here is something i was considering doing
1) Removing enthouht dependency entirely. That would be a pity because it would have been awesome for developing GUIs for demos.
2) developing a fake enthought/chaco package so that those will be imported when the actual cannot be imported due to any reason at all.
3) May be we should consider developing a sub package pyNCS.ui which will support GUI stuff and will ofcourse only work when possible. I dont have a clue at this moment how this will work. This would be in the direction you were suggesting.
Which do you prefer ? And how urgent is this issue ? Option 1 would be the quickest and 3 the slowest.
Actually 3) is pretty good.
For example, you could have Parameter inherit from a HasTraitsAble (virtual) class that would have the functions necessary to cast it into a HasTraits. It is not urgent since there is a work around for this problem using the virtual framebuffer (xvfb).
I also favour the 3rd option. Maybe it is going to be easy to implement with the guiqwt thing.
New branch "headless" added. Unit test runs without errors. Can you guys beta test ? Thanks.
I noticed that pyNCS does not load if no display is available. This is annoying if one wants to run through ssh in combination with nohup (I use this for starting a long experiment through ssh and leave at night). This can also be a problem for Mac users connecting to a server through ssh and that have no local X server.
The cause is traitsui.api in ConfAPI.py . The parameter object inherits from hastraits. There seems to be no easy way to cut its dependency to display. Enthought is certainly a nice tool in some cases, but documentation is awful for a package of its size and importance. So I am wondering whether we should get rid of any enthought calls in the core part of pyNCS (i.e. whatever is imported in init).
A workaround for the display problem is to use a virtual frame buffer: xvfb-run --server-args="-screen 0 1024x768x24" python my_pyncs_script.py