>I must admit though that:
>- the good old VFP9 applications I run have grown wildly with a lot of complex UI (especially in the field of D'nD) that are would be still be possibly better served by fully workstation-based programming frameworks à la >MS or QT,
>- I am looking for some sort of long-term stability that would not be C++ or java-based (do not start me on dotnet). I undertand that looking for stability on a scripting platform is somewhat against the nature of things >though:)

>As quite of a few here on the UT, I love python as much as I did VFP. As the current juncture, I reckon that the QT-based solutions provided by pyqt and, possibly, pyside are still my best bet since wx scripting solutions >such as wxpython may never proposed the long-term decent environments I was expecting them to deliver. But these python+qt solutions incur some massive work for industrial deployment on more than one market >platform...

T>here are times I fondly remember the time when deployment was simple stuff... Of course It can still be when you produce delphi or C++ monoliths. But well, that looks like old-timers stuff:)

Don't count wxPython out yet! I wrote an email yesterday and got some response from the community and it sounds very positive (contact me off line and I can provide the details). As you may be aware I'm involved with Dabo (sort of a take off on VFP) and moving forward - meaning using python 3 and some new features- is very important to me. I think there is reason to wait before you give up on wxPython. I believe it will be only a short period of time before the wxPython is again live and well.

I have always said that the Qt lib was a much better GUI lib over wx (PyQt vs wxPython) But PyQt comes with lot's of work and some money. The negatives are deployment, and the fact that Qt is changing very quickly - a new version very 6-8 months. I guess the change can also be a positive. Also I would have to design new mixin's to handle the CRUD apps that we all do. PyQt has something call 'dip' but I couldn't get it to work (it's also unfinished). When I asked about support for 'dip' I was told I was on my own! So writing code to simplify data interaction with screen and code is not all that easy with PyQT. Just sub-classes for normal widgets is a job that would take lot's of time. Recall that you would be moving between Qtquick and python and python back to Qtquick.

I so love Python that I am still looking for some way to continue using it for the future. That said, I had to give up Fox once!

Johnf