Am 16.03.2014 um 22:11 schrieb Chris Morley <[email protected]>:
>
> Why not change all params so they are read or write (not rw) and
> can have signals connected to them.
that is what I'd suggest too
In an overall scheme of replacing HAL params by something better, I think its
entirely in scope to consider new HAL attributes of pins - there is no good
reason to remain locked-in to the current set of HAL objects and attributes
when considering this. Example - a pin attribute which makes a signal inherit
the pin value on linking.
> If the signal is not connected it uses it's default setting other wise
> it follows the signal - we have a few pins like this already.
I'm lukewarm about instantaneous 'parameter' pin changes caused by linking to a
signal - nasty surprises possible. Not sure this is a good idea, at least not
until there is a clear delineation of 'setup phase' versus 'execution phase' in
a .hal file. There is a mechanism in HAL ("locks") which could be built upon
but it isnt brought up to the halcmd level.
There should be a single place for default values of parameters. We are
currently creeping towards 3 (three!!!): the compiled-in pin default value, a
INI value, and a widget default value.
Going forward you might have more than one UI connected, and hence widgets on
various hosts. These could have default values too. So make that 3+ places.
I am not theorizing here, we are already there, see:
https://www.youtube.com/watch?v=1z9Cw_1hqRg&feature=youtu.be - the code already
does handle the situation of pin default values in the presence of several UI's
(only the first instance gets a chance to set them (if a component option is
set), later UI's are trackers - not sure this is the long-term solution though)
Side note: these clients do not share a filesystem, and that was it for the
inifile scheme. We need to come up with something better downstream which
addresses distributed setups without copying inifiles to every candidate
platform - that wont scale. But that is not the topic here.
In the minimum we need a hierarchy of precedence how initial values are set
(this addresses pins for comp parameter use only, not as a general rule for
pins created by UI's).
My idea would be:
- a compiled-in default is used unless overridden.
- one should be able to use a compiled-in default value, and make it subject to
UI modification without destroying the compiled-in value.
- there should be a single mechanism for a default override.
- an override should be in a single place (because of possible multiple UI's).
- downstream a persistence mechanism for such 'parameter' pins makes sense.
- there needs to be a rule how widget default values relate to parameter
default values. The above suggests: ignore them altogether, and make the UI
track the default - however that is derived.
makes sense?
- Michael
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
