On Thursday, February 6, 2003, at 02:10 pm, David Megginson wrote:
I think that we can centralize this and make it invisible to JSBSim
and other suppliers of property values. Polling inside the property
manager makes sense, since
a) it will be done only on demand (when someone assigns a
James Turner writes:
I think that we can centralize this and make it invisible to JSBSim
and other suppliers of property values. Polling inside the property
manager makes sense, since
a) it will be done only on demand (when someone assigns a listener to
a property),
On Thursday, February 6, 2003, at 01:56 am, David Megginson wrote:
If so, seems like we're kind of shooting ourselves in the foot or
am I just being super-anal and should just poll them as Jim Wilson
suggests?
This is a good discussion to start. I'm inclined to eliminate tying
James Turner wrote:
Basically, I can envisage lots of things the ChangeListener API is
perfect for, whether you're observing a value that changes one a week or
50 times a second, but right now those things won't work because some %
of the properties don't tell you they've changed. Now, we
Erik Hofman wrote :
James Turner wrote:
Basically, I can envisage lots of things the ChangeListener API is
perfect for, whether you're observing a value that changes one a week or
50 times a second, but right now those things won't work because some %
of the properties don't tell you
On Thursday, February 6, 2003, at 10:16 am, Frederic BOUVIER wrote:
Aren't the C++ opperators the perfect place to add this kind of action
to tied properties?
I had the same idea reading the message from James.
imagine that template (we are not against templates, aren't we ? ;) :
template
James Turner wrote :
The impression I have is that a bunch of code uses 'tieing' to expose
lots of internal variables directly. I'd prefer an explicit
'publishing' phase, i.e calls to setValue. Of course your template
works fine too, if you're prefer the syntactic sugar.
I see your (rather
James Turner wrote :
I do, but this is not the problem (as I understand it). The tie-ing
system is 'low-invasion' for existing code / code which may not be part
of FG, and works well with existing state variables. Your template /
operator overloading fix the syntax, but I sort of think that's
On Thu, 2003-02-06 at 01:09, James Turner wrote:
On Thursday, February 6, 2003, at 01:56 am, David Megginson wrote:
excerptexcerptIf so, seems like we're kind of shooting ourselves
in the foot or
am I just being super-anal and should just poll them as Jim Wilson
suggests?
Tony Peden writes:
This is a good discussion to start. I'm inclined to eliminate tying
altogether and have every module set properties explicitly; what does
everyone else think?
I'd really like to see tying stay in. I'm not sure we ever would have
incorporated the property tree
Frederic BOUVIER writes:
But I don't think there is a huge penalty here. Classes that are doing
tying now must store the SGPropertyNode as a separated pointer for tying
and untying.
They don't, actually -- the property manager takes care of storing the
node. You just do something like
1. Require every module that ties a property to fire an update event
whenever the value changes; or
2. Poll tied properties with change listeners attached inside the
property system and fire the events when appropriate.
I'd be include towards #2, since it would centralize the polling
Jon Berndt writes:
Let me add that in JSBSim (and for that matter probably any FDM)
just offhand I'd say that almost all of our properties will be
changing every single frame. Aircraft state and EOM are dynamic
things.
I think that we can centralize this and make it invisible to JSBSim
James Turner writes:
This was a two hour hack I did to learn a bit more of the code, it was
fun to do, and the end result is quite nice. It could use some polish
(rounding off some digits), and while performance seems okay I'm
worried on 'big' nodes it might be a hit. I'm simply using
David Megginson [EMAIL PROTECTED] said:
Currently, the property tree knows about changes only when someone
changes a value through it; when a property is tied to C++ code, the
valueChanged() method is never fired.
Sounds like a better technique would be to just reread the current
On Wednesday, February 5, 2003, at 05:42 pm, Jim Wilson wrote:
Currently, the property tree knows about changes only when someone
changes a value through it; when a property is tied to C++ code, the
valueChanged() method is never fired.
Sounds like a better technique would be to just reread
James Turner writes:
I'm pretty adamant that's the wrong way to do this, we're reduced to
polling. Being anal for a second, SGPropertyNode is an interface, and
therefore is supposed to make some guarantees about it's behavior. One
of these is that changeListeners are correctly invoked. Sure
Jumping in here, just to prove to folks that I'm still alive. :)
James Turner wrote:
I'm pretty adamant that's the wrong way to do this, we're reduced to
polling. Being anal for a second, SGPropertyNode is an interface, and
therefore is supposed to make some guarantees about it's behavior. One
James Turner [EMAIL PROTECTED] said:
If so, seems like we're kind of shooting ourselves in the foot or
am I just being super-anal and should just poll them as Jim Wilson
suggests?
Ummm...it's not polling, it's just updating the data. Same as many of the
subsystems do every frame.
Curtis L. Olson [EMAIL PROTECTED] said:
Looking at it another way, if the user has the property browser open,
they are probably more concerned with debugging and could put up with
a very tiny frame rate drop (while the debugging window is open.)
There is already going to be some performance
James Turner writes:
If so, seems like we're kind of shooting ourselves in the foot or
am I just being super-anal and should just poll them as Jim Wilson
suggests?
This is a good discussion to start. I'm inclined to eliminate tying
altogether and have every module set properties
On Wed, 2003-02-05 at 17:56, David Megginson wrote:
James Turner writes:
If so, seems like we're kind of shooting ourselves in the foot or
am I just being super-anal and should just poll them as Jim Wilson
suggests?
This is a good discussion to start. I'm inclined to
On Wed, 5 Feb 2003, David Megginson wrote:
James Turner writes:
If so, seems like we're kind of shooting ourselves in the foot or
am I just being super-anal and should just poll them as Jim Wilson
suggests?
This is a good discussion to start. I'm inclined to eliminate tying
23 matches
Mail list logo
