[GRASS-dev] making py.monitor listen to external commands
Michael Barton
michael.barton at asu.edu
Tue Jun 13 01:44:31 EDT 2006
It's worthwhile to see how we've done this same kind of thing in the GIS
Manager console using TclTk.
If the commands are done through the GUI or a python command console, it
really isn't necessary to constantly listen for commands because the user is
the one who issues commands. These commands can be captured at the time they
are issued by the user and echoed back to the command history console. The
stdout and stderr from each command can also be captured and echoed back.
Since all this is simply text (commands and their output), it can go into a
scrolling text widget producing a history of commands and output.
In other words, this can be be event driven in a simple, straightforward
manner. Pressing "run" button (if default, pressing return) runs a command
and echoes the command to history. When a command is issued, its output is
automatically captured and sent to history.
This done in a more sophisticated way in the gronsole that Cedric Shock did.
It separates commands from their output and allows the output to be folded
out of sight. Buttons that are put into the text widget alongside each
command will automatically copy the command from history back to the command
console where it can be edited and run again.
Hope this helps
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
> From: Jachym Cepicky <jachym.cepicky at centrum.cz>
> Date: Mon, 12 Jun 2006 21:47:22 +0200
> To: David Finlayson <david.p.finlayson at gmail.com>
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] making py.monitor listen to external commands
>
>
> On Mon, Jun 12, 2006 at 12:36:32PM -0700, David Finlayson wrote:
>> One thing that might be helpful is to have a file which lists the
>> currently displayed ppm images (in the monitor) in the order that they
>> are displayed. Then a command line program could replace the list with
>> new data (d.erase) or append to the list (d.rast -o). The monitor
>> would need to check if the list had been changed and then update
>> itself (maybe after receiving an update yourself signal via a socket)
>>
>> Ideally, the monitor list would contain enough information to update
>> the gis.m widgets as well.
>>
>> In other words, d.erase would erase the monitor and (optionally) also
>> remove all the drawing "widgets" from gis.m. Issuing a d.rast command
>> would, in addition to updating the monitor, replace or append to the
>> gis.m widgets as appropriate.
>>
>
> yes, yes, that is no question about what it should do
>
> def watcher(self):
> commands_file = "py.commands"
> commands = open(commands_file,"r")
> st_results = os.stat(commands_file)
> st_size = st_results[6]
> commands.seek(st_size)
>
> while 1:
> where = commands.tell()
> line = commands.readline()
> if not line:
> time.sleep(1)
> commands.seek(where)
> else:
> line = line.strip()
>
> if line == "d.erase":
> self.commandsCtrl.SetValue('')
> else:
> self.commandsCtrl.SetValue(
> self.commandsCtrl.GetValue()+"\n"+line+"\n")
>
> But how?
>
> I have rewritten the code a bit, but it does not seem, that both
> processes would have same space in memory :-(
>
> class Monitor(wx.App):
> def OnInit(self):
> ...
>
> try:
> pid = os.fork()
> if pid == 0:
> self.watcher()
> else:
> print self.semafor
> print "otec"
> except OSError, e:
> # no fork
> sys.exit(1)
> return True
>
> It would be maybe better, do it in MainLoop, but I did not found the
> approach, how to smuggle watcher() in the MainLoop :-(
>
> Jachym
>
> --
> Jachym Cepicky
> e-mail: jachym.cepicky at centrum.cz
> URL: http://les-ejk.cz
> GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
> -----------------------------------------
> OFFICE:
> GDF-Hannover
> Mengendamm 16d
> 30177 Hannover
> Germany
> e-mail: cepicky at gdf-hannover.de
> URL: http://gdf-hannover.de
> Tel.: +49 511-39088507
More information about the grass-dev
mailing list