Re: GPGET('terminal')

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 16 April 2006 12:33 pm, Petr Mikulik wrote:

> a = GPGET("terminal")   =>  return "x11"
> a = GPGET("termoptions")   =>  return "enhanced noraise"
> xmin = GPGET("xmin")    =>  return min of xrange of the last plot
> ... GPGET("xmax"), "y2min", "cbmin", etc.

> Only few variables, the most important, should be availabe now -- others 
> could be added on user's request any later, without poluting the user 
> space with new var/funcs.

I'm not convinced that polluting the name space is a problem.
We could simply agree to use only variables beginning with
MOUSE_ or GPVAL_ or FIT_ or whatever, and document that users should
avoid creating private variables starting with these character strings.

Exporting a new internal variable as a user-visible one requires only
3 lines of code. Parsing for your proposed GPGET option would be more
cumbersome, I think, and would require making all exportable variables
global.

	struct udvt_entry *name = add_udv_by_name("GPVAL_XMIN");
	Ginteger(&name->udv_value, xmin);
	name->udv_undef = FALSE;
> 
> What do you think about GPGET("xmin") et al?
> Or putting the plot ranges into XMIN, XMAX, etc?

I think we should export internal values as user-visible variables
with a fixed naming scheme.  See also feature request 

	#1117724 [fit] access to resulting chisquare


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742