> From: Erik Hofman 
> Jim Wilson wrote:
> > Hmmm...so why would that make a difference on the pui end?  It makes more 
> > sense that the requirement of an active read (that
> is bound to a subsystem owned getter) would be the cause of no on screen 
> update.  I don't think the pui would care who owns the
> value, does it?  Sorry I haven't looked at the code and don't have time to 
> now.
> > 
> > Actually I'm now wondering why we don't just do a once per frame refresh of 
> > the browser so that the display always updates
> per frame (only while that dialog is displayed).  It wouldn't cost all that 
> much and would certainly increase the utility of the
> browser.
> Curtis is right, the property browser uses a callback function provided 
> by the property code which is only called for properties that don't use 
> the Tie() function (It has been discussed in the past to add the same 
> functionality for all properties but it either requires C++ operator 
> mangling or a function that checks for a change every frame).

Actually it is a change listener.  Maybe I misunderstood what Curt was saying,  
but AFAIK the "Tied" properties you speak of are bound to subsystem defined 
getters/setters not C++ variables.  Of course, probably there is something else 
I'm not aware of.

Regarding property picker refresh, on further reflection probably an N times 
per second approach to refreshing the widget would be better than per frame.  
Anyone interested could perhaps make gui.cxx into a proper flightgear subsystem 
and do it from there.



Flightgear-devel mailing list

Reply via email to