I am working with a few people (most notable Sam Rushing -
email@example.com) on a GUI project. We are developing under
NT, and will target Windows 3.1/Chicago.
I am currently with 1-0-0, and once I understand exactly what I am
doing, I will make the changes to 1-0-2.
To date, I have built Python for NT, and implemented Dynamic Loading, so
any compiled extensions can be loaded as DLL's. Ultimately this means
that anyone will be able to pick up a vanila Python, and have it
pick up their compiled extension without any Python source changes.
Also please note I am a python novice. Please dont flame for
mis-understandings of Python.
The first step in getting Python to run in a GUI environment was to try
and emulate the interactive input that Python gives you. This is where I
found my problems:
run_tty_loop ends up calling parsefile. This function ends up in a loop,
waiting for a statement to be completed. If a multi-line command is
types, parsefile() never returns (until complete of error detected).
This is not suitable for a GUI program, as the program can not be
"blocked" waiting for line based input.
A solution for me would be to have a function similar to "run_command",
except that it would allow the first line of a multi-line command, but
return a result indicating that the statement is incomplete. The next
call could be made to complete the statement. Obviously, the return
value would have the state of the statement up until the current end of
input. This state info would be passed back to subsequent calls.
My other problem is what seems to be "fprintf(stderr,...)" calls
throughout the code. In a Windows environment, grabbing this stderr
output so the program can use it is not trivial. My standard solution
to this sort if thing is to provide:
void ErrorOutput( char *format, ...)
vsprintf(buffer, format, first_arg);
Then, for _my_ purposes, I provide a custom "ErrorOutput" that (say)
appends to a global bufferm that can later be viewed.
Does anyone have any comments on any of this stuff? Any advice