Re: heatbugs suggestion

[glen e. p. ropella]

"rlr" == Rick Riolo <address@hidden> writes:

rlr> Hi Glen, Yes, I could see this as some kind of object editor.  If
rlr> I understand it correctly, now probes can serve double duty as a
rlr> measuring device and as an changing device.  Maybe a subclass of
rlr> probes could be the "change" interface.  Or maybe its on a
rlr> different class branch.  I don't have an opinion on how its
rlr> implemented, really.

rlr> My main point goes beyond heatbugs...heatbugs is just an example
rlr> of where it would be useful.  I have found general data entry
rlr> interfaces to be most convenient if I (the programmer) can define
rlr> special methods to process the incoming data and then tell the
rlr> interface "when a user enters data for this, execute this
rlr> method", no matter how they enter data.  Then that user-defined
rlr> method can do error checking, to convert data (eg from the user
rlr> entering some string name for the value to an internal enum
rlr> value), to pass the value from this variable to other objects (if
rlr> they exist), and so on.

Hmmm.  You seem to be talking about two different things (which,
of course, means that I simply don't understand what you're saying :-).
On the one hand, there is the generic "apply" button one might see
on user interfaces all over the place, where the user may make 
several changes to widgets in a given window, then hits "apply" to
make them take effect.

Then on the other hand, you're talking about "data receivers" inside
the objects themselves that do some bounds or validity checking on
the data that's passed to them.

The latter doesn't seem to fit nicely in the "probe" framework.
Probes are intended to be devices with which one gets at the 
instance variables and methods *without* explicitly designing
the object to handle such.  That specifically eliminates the 
idea of having a "data receiver" inside the object to accept
input from probes.  Now, it doesn't mean that there shouldn't
be some other "piping" mechanism that would actually be a part
of the agent in receiving and sending data through channels other
than the probes.  That would be a decent place to put bounds and
validity checks.

The former is certainly an issue.  WE've always had problems with 
using probes as user interfaces and "knowing" as users if the 
thing we just typed actually went to the object.  I remember getting
a demo of Village from Eric Carr during my interview where he
typed a value into a probe widget and then proceeded to hit return
2 or 3 times.  I think I even asked him why he did that. [grin]
This might suggest that instead of using the red hilighting box
around the widgets to indicate that a value has been set, we
could implement an "apply" method.

rlr> ps I thought I was up early, but you are 2 hours earlier!

Ahhh, but I'm MST and you're probably EST, eh?  So, in relativity,
we probably get up about the same time.  The real difference is
that I work for about 3 hours in my pajamas before I take a 
shower and report to work, proper.

glen