[visionegg] Re: GUI parameters windows
- From: "Gabriel Nevarez" <nevarezg@xxxxxxxxxxxxx>
- To: <visionegg@xxxxxxxxxxxxx>
- Date: Fri, 06 May 2005 13:22:14 +0100
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: //www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html
======================================
The Vision Egg mailing list
Archives: //www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html
Other related posts:
