Hank,
>
>I have the same experience: python feels natural to me.

yupp, same here. Unless db/table work is needed, feels even better than vfp - even with less than 5% of practice time.

>The UI framework that interests me the most, because that's where I see apps moving, is Pyjamas. It desperately needs a good UI design environment, e.g., the Dabo editor converted to work with Pyjamas, and perhaps polished a bit more (there aren't many FOSS projects that don't need some polishing, Python being the exception that proves the rule). I believe it will happen, and then we will all be happy programmers, being just as productive in Python as we were in VFP. Pyjamas itself needs to move to GWT2.2, of course.

I think that Dabo moving to some GUI besides wxWidgets is not that probable anytime soon.
While the DB classes are clearly made for switching backends, but wx is too entangled into the GUI code.

The earlier target of multiple GUI availability after 1.0 seems to be not high on their current list -
with the springboard technology a pure web interface is unneccessary if you restrict yourself to i86/i64 based HW.
Phones/Pads seem not to be on their target list - AFAIR pyjamas was played down last year,
which I personally believe to be premature unless something better can at least be demonstrated, if not used ;-)

Currently the code works - separating wx specifics from pure python GUI code mostly is drudgework,
but unless a Pyjamas front end is worked on very soon, that drudge work is for almost useless.
And for the Pyjamas GUI you start with zero compared to a running wx - reminiscent of egg an dinosaur.

If you get Ed and Paul and the others to test the separation of PyGUI and wx specifics, it should not be a hard
task (I might even take a stab at half a dozen source files) if the attack vector is clear.
IMHO something similar to the cursormixin for the backend is "better python"
than a inheritance based approach which would also work, but should be set by the fwk authors.

And to be honest - for me more temptimng as the first try would be to enhance the fwk
to use update conflict managment based on pk and rowversion:
I standardized all my multiuser access around that pattern last century and
think still it beats any other form of conflict management, including "no conflict management".

>And of course, we would want to be able to convert existing VFP forms into Pyjamas widgets. That should be something right up your alley, I would think. <s>

That is another thing I might offer some help:
I could re-use part of the my code making vfp forms run as Ironpython Winforms ;-)

But currently my paid work is again more in the pattern building/datamining/SQL sector via vfp:
here I am nowadays actively using SQLite as "workstation data store"
for all files > 2GB (no more splits!), giving me a better handle on that vector.

Works rather well - I can build on that if I feel the need for a local SQL cache ;-)

regards

thomas