ETS traitsui and pyface update to Phoenix woes

[braide...@gmail.com]

Hello,
I have managed to translate/update ETS traitsui/pyface using the translation template so that the samples I have tried, from very simple to very complicated, will run all the way until they segfault at the "app.Mainloop()" statement. This is a reasonable accomplishment given the complexity of the package, but very frustrating to be so close and yet so far. I wish I could give better detail, but had a challenging time to just to get it to fail consistently at the GUI invocation.

In addition to the translations, 1. some encoding needed modification (so far a special test for JPEG data), 2. byte-type to unicode issues noted elsewhere, 3. some colors needed strong typing as int, and  4. the SetSize only accepted a wx.Size argument or would otherwise segfault. The color type mismatch was picked off by Python, but I suspect there may be some subtle data mismatches are most likely responsible for the crashes/

I am running Linux Mint Cinnamon 18.1x64,with Phoenix_dev is installed and running ALL but MSW-widget demos flawlessly, a first for me on any platform.

I am very happy to see WxPython back on track and appreciate the efforts made by all the developers.

Cheers,
Eric

[Rob McMullen]

This is very interesting; I did some of the work porting pyface to wxPython 3.0.2 after Enthought gave up support of Tasks on wx. I've been wanting to try to start the port to Phoenix but I'm still holding at wxPython 3.0.2 classic. And Python 2.

Are you on Python 2 or 3?

How does the pyface stuff by itself work, without the traitsui parts? Most of the examples in the pyface/examples directory don't use traitsui.

Do you have something on github or wherever that I can check out to try to help?

Rob

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[braide...@gmail.com]

Thanks for the pyface tip. All but one example fail, but most of the failures have error messages rather than segfaults. I will trace down some of the errors and see if I can't get a few more examples operational.

I have no public repo yet. I will see if I can get just a bit farther before I post anything, and the first pass will likely be an archive with my updated files.

[braide...@gmail.com]

Question/suggestion regarding pursuit of pyface examples was pretty fruitful. So far:

application_window.py - opens up
dialog.py - Okay
expandable.py - works
explorer.py - okay
file_filters.py - imported
file_node_tree.py - imported
file_sorters.py  - imported
file_table_viewer.py - imported
file_tree.py  - imported
file_tree_viewer.py  - imported
hello_world.py  - okay
image_widget.py  - okay
mdi_application_window.py - okay
menu_manager.py - okay - not gui
multi_toolbar_window.py - okay, but get message ->Debug: ScreenToClient cannot work when toplevel window is not shown"
node_tree.py  -  good
progress_dialog.py - good
python_editor.py - good
python_shell.py - good
splash_screen.py - okay, but splashscreen flashes up too fast
timer.py - good
tool_palette.py  - works
tree.py   - fine - same as node_tree and tree_viewer??
tree_viewer.py - fine

ipython_shell.py - FAILS due (at the least) to outdated IPython usage

TraitsUI dependency failures:
chained_wizard.py - Segmentation Fault
grid.py - quickly flashes up then seg faults
traitsui_window.py - segfault
wizard.py - segfault, Debug: wxColour::Set - couldn't set to colour string '(255, 0, 0, 255)
All examples buried below the first level


The appearances of many windows are rough, with many size and sizer issues, but on close inspection it doesn't look like these example apps are trying to accomplish much.

On my traces of traitsui demos, the things that for certain trip a segfault:

1. traitsui/wx/toolkit.py ->class GUIToolkit->position  window.SetSize or window.SetPosition with any possible arguments for those methods. The "window" here appears to be for top level.
2. pyface/util/guisupport.py -> function start_event_loop_wx ->app.Mainloop().
3. No direct evidence, but various debug errors have problems with some color setting.

The second item is doubtless reflecting some other mistake, because the same routine is invoked for using many of the successful pyface example apps. Also, invoking SetSize or SetPosition causes no problem for any of the wxPython demos I've tried.

I'll chug along for another day or two trying to track the problem down, but I'd definitely appreciate any suggestions about possible places to check.

Cheers, Eric

[braide...@gmail.com]

Hello,

All of the traitsui demos still segfault, but the only consistent thing between failures is that the faults are triggered by calls to events. Of the demos I've run through gdb, no two scripts fail on the same event. Furthermore, a couple of specific interesting behaviors:
1. on the wizard.py demo, as noted in my last message, wxWidgets catches an attempt to update a color with a string '(255,0,0,255)' rather than a tuple. This is interesting for three reasons (a) something is triggering a change-color event (b) the event is sending str('(255,0,0,255)') and the current value is listed as u'(255,0,0,255)' and (c) the comparison shows these two to not be equal. I have no idea why it would want to send or use strings, because all of the color traits are actual tuples and not strings.
2. In the grid.py demo, under a Windows 7-x64 VM (but not the host Linux Mint Cinnamon 18.1 64-bit), the grid comes up briefly with the row and column labels, and column 1 populated with text elements, but nothing in the other 3 columns of non-text elements. On Linux I get no gui popping up, but I can stop the Python script just prior to segfaulting. In winpdb, I can make changes to the traits table entries or the underlying traits row data, or I can change the cells directly with the methods of the wxGrid object. When I make changes to the grid object, these are pushed immediately down to the lowest trait data object. On the other hand, changing the traits data directly does not change the corresponding grid object.

All of this leads me to believe that some intermediate mid-level event binding isn't taking place. I would certainly welcome any other theories though.

BTW, my ultimate objective in all of this is getting Mayavi functional with the latest wx.

Cheers, Eric