[visionegg] Re: GUI parameters windows

Dear Gabriel,

My initial response is to suggest looking at the ephys gui/server already in the Vision Egg. I'd like to highlight some recent work from Imran Ali and Lachlan Dowd in the lab of David O'Carroll at the University of Adelaide now allows simple demo-like scripts to be controlled from the GUI. I haven't had time to make docs for this yet, but in recent months the CVS version of the ephysgui has had an extra item in the file menu called "load demo script" or something like that which loads these things. I hope this will make tasks like yours easy, but I'm afraid that if you're using this for psychophysics, it will be difficult to record responses easily. (The name "ephys" in the title says what this was designed for...)

More generally, this approach uses a separate process for the GUI and the Vision Egg display code (the "server"), communicating over network sockets. This allows them to run on completely separate machines, which is nice if you're also doing data acquisition on the GUI code (there are hooks in the ephys GUI for extending it, but it could also be done in yet another process). Generally, you'll have to separate the GUI mainloop from the stimulus display mainloop (whether you use FlowControl or not). Sending information between threads doesn't seem to be particularly easier than sending information between processes (in my experience, although it _might_ be faster for passing large amount of data, it also introduces significantly more potential for bugs). So, I'd suggest separate processes to give the possibility to use separate computers if need be. (And if you go this route, let me plug Pyro.)

There's another possible approach, which sounds very appealing, and may only require one thread: make the stimulus display process also a web server. The experimenter's web-browser would then be the GUI. When timing is cricital, the server/display process could ignore the network sockets but otherwise would poll for new requests. Previously, I would have avoided this approach because I always wanted the server to be able to push information to the (browser) gui, but I recently was very impressed with just this ability in the LivePage feature of the Nevow web toolkit for Python. Just an idea, but pretty interesting...

Let me know if I didn't quite get what you're asking...

Cheers!
Andrew

Gabriel Nevarez wrote:

Hello, all, 

Another issue as I'm thinkin about this problem:

Would it be possible to run the GUI object as a separate thread?  If so, how
would this affect mainloop performance?  It would be nice to have a parameters
window that can be called up arbitrarily while a study is running to make
parameter changes on the fly, without imposing a large performance penalty.

As my experience with python and threads is limited, does anyone know how such
an approach would affect performance?

-=Gabriel Nevarez
Research Programmer
Psychology Department
Cardiff University
http://www.cf.ac.uk/psych



nevarezg@xxxxxxxxxxxxx 05/06/05 12:56 PM >>>


hello, andrew and all,

Coming into VisionEgg from other experiment environments, one of the things I
sorely miss is a GUI parameters window, so I'm going to try to code my own. However, I've never done GUI programming, so don't know what the best way to go
about doing this is.

The gui itself isn't the hard part.  Typically, it's just setting up a bunch of
callback functions as menu options, or something like this:

gui = GUI.new()
gui.setup(parameter = "numTrials",
            min = 0,
            max = 100,
            type = "integer",
            position = (0,0)  # coordinate position in gui parameters table
            )

and so forth.

that's easy... what I would like to do, though, is be able to create a generic
container, so that I could add any arbitrary type of parameter, even those not
anticipated by the gui class. Dunno if this can be done through callback
functions, and if so, if it can be done in python. 

something like:

gui = GUI.new()
gui.setup (parameter = "gabor_type",
             setup_func = parameter_gabor_setup()
            )


whereupon parameter_gabor_setup() takes care of defining the initialization 
of
the parameter, and thus leaving the gui class as a generic container.

ideally, something even more generic: creating an intantiation of the
parameterized object and simply passing this object to the gui.setup() function,
thus having the gui container determine the gabor properties based on the object
properties of the gabor class.  something like:

gui = GUI.new()
gabor_01 = gabor.new() # or equivalent constructor function

gui.setup (gui_text = "gabor_type",
             object = gabor_01)

or even having the gabor class (and any subsequent classes to be used with the
gui) having built-in self-declaration properties, just in case they need to be
referenced by any such container as a gui container, such as:

gabor.parameters.gui_text = "gabor_type" # and so forth, gui.setup(gabor_01)

Thus the creation of objects would necessarily require stating parameter
limits... might be overkill, though.

Has anyone tried doing anything similar? Trying to come up with a good balance
of "generic-ity" for the gui container.

cheers, Gabriel Nevarez
Research Programmer
Psychology Department
Cardiff University
http://www.cf.ac.uk/psych




======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html




--
Andrew D. Straw  Post-doctoral scholar
,-.              Dickinson Lab
\_/              California Institute of Technology
8||}             Mailcode 138-78
/ \              Pasadena CA 91125, USA
`-^
                email:  astraw@xxxxxxxxxxx
                 office: +1 626 395 4396


======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Other related posts: