By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,166 Members | 1,777 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,166 IT Pros & Developers. It's quick & easy.

sending input to an embedded application

P: n/a
hi, I'm a novice programmer trying to better define a hobby project
I'm thinking of.

What I would like to do is take a program and embed it or put it
within a Python-run GUI, using the GUI just to capture and send input
to the application, and display the ouput.

Specifically I want to use a Python module such as wxPython, pygame or
pyglet to build the UI, capture key presses, and then send a string to
the program, an interactive fiction interpreter; the reason for this
is that the interpreter on its own doesn't have the capability to
recognize certain key presses on the keyboard. I thought that writing
a middle layer rather than a brand new interpreter would be easier for
someone of my skill level.

The interpreter would send its output to the Python GUI. The GUI then
would be as light/translucent as possible, just accepting input,
sending it to the interpreter, and displaying the output as if you
were just running the interpreter by itself.

As I don't really know the issues involved, I'm hoping someone can
point me in the right direction. Do people 'frame' programs with
something like wxPython or pygame and use the frame to capture and
pass along input, and receive and display the output?
thanks, George
Jul 12 '08 #1
Share this Question
Share on Google+
4 Replies


P: n/a
On 12 Jul., 09:08, George Oliver <georgeolive...@gmail.comwrote:
hi, I'm a novice programmer trying to better define a hobby project
I'm thinking of.

What I would like to do is take a program and embed it or put it
within a Python-run GUI, using the GUI just to capture and send input
to the application, and display the ouput.

Specifically I want to use a Python module such as wxPython, pygame or
pyglet to build the UI, capture key presses, and then send a string to
the program, an interactive fiction interpreter; the reason for this
is that the interpreter on its own doesn't have the capability to
recognize certain key presses on the keyboard. I thought that writing
a middle layer rather than a brand new interpreter would be easier for
someone of my skill level.

The interpreter would send its output to the Python GUI. The GUI then
would be as light/translucent as possible, just accepting input,
sending it to the interpreter, and displaying the output as if you
were just running the interpreter by itself.

As I don't really know the issues involved, I'm hoping someone can
point me in the right direction. Do people 'frame' programs with
something like wxPython or pygame and use the frame to capture and
pass along input, and receive and display the output?

thanks, George
Which interface does your interpreter provide ? Just commandline or
can you access by other methods ?

http://sourceforge.net/projects/pexpect/ might help you

Greetings, Uwe
Jul 12 '08 #2

P: n/a
Uwe Schmitt wrote:
On 12 Jul., 09:08, George Oliver <georgeolive...@gmail.comwrote:
>What I would like to do is take a program and embed it or put it
within a Python-run GUI, using the GUI just to capture and send input
to the application, and display the ouput.

Which interface does your interpreter provide ? Just commandline or
can you access by other methods ?

http://sourceforge.net/projects/pexpect/ might help you
Although Pexpect looks more advanced and complete, you might want to take a
look at popen* modules. It enables you to easily run a subprocess, feed him
data on stdin, retrieve output from stdout/stderr, and wait for its
completion.

http://docs.python.org/lib/module-popen2.html

--
mefyl
R&D engineer at Gostai - http://www.gostai.com

To understand recursion, you must first understand recursion.
Jul 12 '08 #3

P: n/a
mefyl wrote:
Uwe Schmitt wrote:
>On 12 Jul., 09:08, George Oliver <georgeolive...@gmail.comwrote:
>>What I would like to do is take a program and embed it or put it
within a Python-run GUI, using the GUI just to capture and send input
to the application, and display the ouput.
Which interface does your interpreter provide ? Just commandline or
can you access by other methods ?

http://sourceforge.net/projects/pexpect/ might help you

Although Pexpect looks more advanced and complete, you might want to take a
look at popen* modules. It enables you to easily run a subprocess, feed him
data on stdin, retrieve output from stdout/stderr, and wait for its
completion.

http://docs.python.org/lib/module-popen2.html
I believe the subprocess module is the recommended module to use now.

-Matt
Jul 21 '08 #4

P: n/a

Matthew Fitzgibbons wrote:
>
mefyl wrote:
>Uwe Schmitt wrote:
>>On 12 Jul., 09:08, George Oliver <georgeolive...@gmail.comwrote:
What I would like to do is take a program and embed it or put it
within a Python-run GUI, using the GUI just to capture and send input
to the application, and display the ouput.
Which interface does your interpreter provide ? Just commandline or
can you access by other methods ?

http://sourceforge.net/projects/pexpect/ might help you

Although Pexpect looks more advanced and complete, you might want to
take a
look at popen* modules. It enables you to easily run a subprocess,
feed him
data on stdin, retrieve output from stdout/stderr, and wait for its
completion.

http://docs.python.org/lib/module-popen2.html

I believe the subprocess module is the recommended module to use now.

-Matt
--
http://mail.python.org/mailman/listinfo/python-list
=====================================

HUMMMMMM!

#
print "popen3 run"
########## from existing python docs:
from popen2 import *

r,w,e= popen3('dmesg | grep hda')
print r.read()
print "subprocess run"
########## from existing python docs:
# "... Replacing older functions with the subprocess module..."
from subprocess import *

p1 = Popen(["dmesg"], stdout=PIPE)
p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE)
output = p2.communicate()[0]
#documentation quits

print p2.communicate()

#
""" Why do children insists on making things more complicated
than necessary? If the stated bragging rights of Python
is that one writes less code to accomplish more, then I
have to say "bullshit", just count the printable characters.

to write less would be to change something like this:
try:
f = open(arg, 'r')
except IOError:
print 'cannot open', arg
else:
print arg, 'has', len(f.readlines()), 'lines'
f.close()
### I have to guess what type error to code for and I'll need another
module to decode what actually went wrong.
to this:
if (fd = os.open(filename, 'O_RDRW|O_BINARY, 0666) == -1)
...handle it
if fd.err.type == THIS #catagory
if fd.err == this #specific
do this
etc.
## just to see what went wrong? print fd.err.type, fd.err
else: #just to match above
continue processing
### error reporting actually usefull

who says fd cannot be simple interger or pointer to error block
depending on whether it's valid or not? The bonus is, if there is
no trap it will stop anyway first time fd is used as a file number.
The crash usually actually points to the correct place. :)

All that aside: subprocess seems to have a problem:

"""
# When I run the above I get:

==============
PY:py test.py
popen3 run
ide0: BM-DMA at 0x1400-0x1407, BIOS settings: hda:DMA, hdb:pio
hda: ST9160821A, ATA DISK drive
hda: attached ide-disk driver.
hda: host protected area =1
hda: cannot use LBA48 - capacity reset from 312581808 to 268435456
hda: 268435456 sectors (137439 MB) w/8192KiB Cache, CHS=19457/255/63,
UDMA(100)
hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 >

subprocess run
('', None)
PY:>
=============

Note subprocess yields unexpected answer. Probably needs better
documentation and less typing. :)

The "PY:" is result of script to change to dir python and set the PATH
py is copy of python renamed to afford less typing. (Unix vs Microsoft)

Note: without lots of extra effort, the piping only works for commands
like grep that are built to accept redirected I/O. I have yet to get it
to work with the GUI type. Those need special things implanted at
compile time because they don't use or even want the command line
interface. Typically they are "Point'n'Click" or take a hike. GUIs are
visually more appealing but don't play well in the production world.

Steve
no******@hughes.net
Jul 21 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.