Re: [Flightgear-devel] property browser
> 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. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property browser
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). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property browser
bass pumped wrote: If I wanted to look at the code for the property browser where would I look? It's prop_picker.[ch]xx in FlightGear/src/GUI Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property browser
If I wanted to look at the code for the property browser where would I look? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property browser
Jim Wilson wrote: >>From: "Curtis L. Olson" >> >>Jim Wilson wrote: >> >> From: Josh Babcock Did someone change the property browser so you can't watch the values change in real time? How do I get this back? Josh >>> >>>Which property are you looking at? It has been a very long time, so I might >>>be a little off here. IIRC the a property node >> >>is only updated if the responsible subsystem (e.g. the FDM interface) writes >>to it. If that subsystem does not write to the >>property then the property only gets updated when the property picker does a >>read which is bound to a getter in the responsible >>subsystem. >> >>>My guess is something changed in the subsystem you want data from, probably >>>by someone trying to save cpu cycles. >>> >>>BTW, if this is what has happened, developers should note that the >>>flightgear will in many cases (probably most cases) run >> >>FASTER if the subsystem that owns a property updates it once every frame. >> >>>Of course there might be a bug in the latest property system work...but the >>>code I have, which is fairly recent, still shows >> >>some real time updates in the property picker. >> >>> >>> >> >>As I understand it, here is how things have always worked. Properties >>that are "tied" to C++ variables don't update automatically. You can >>click on the "." at the top to "refresh" the values. Properties that >>exist soley within the property system will update "live" in the >>property browser. >> > > > 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. > > Best, > > Jim > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > And any cost would go away when you close the browser anyway. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property browser
> From: "Curtis L. Olson" > > Jim Wilson wrote: > > >>From: Josh Babcock > >> > >>Did someone change the property browser so you can't watch the values > >>change in real time? How do I get this back? > >> > >>Josh > >> > >> > > > >Which property are you looking at? It has been a very long time, so I might > >be a little off here. IIRC the a property node > is only updated if the responsible subsystem (e.g. the FDM interface) writes > to it. If that subsystem does not write to the > property then the property only gets updated when the property picker does a > read which is bound to a getter in the responsible > subsystem. > > > >My guess is something changed in the subsystem you want data from, probably > >by someone trying to save cpu cycles. > > > >BTW, if this is what has happened, developers should note that the > >flightgear will in many cases (probably most cases) run > FASTER if the subsystem that owns a property updates it once every frame. > > > >Of course there might be a bug in the latest property system work...but the > >code I have, which is fairly recent, still shows > some real time updates in the property picker. > > > > > > As I understand it, here is how things have always worked. Properties > that are "tied" to C++ variables don't update automatically. You can > click on the "." at the top to "refresh" the values. Properties that > exist soley within the property system will update "live" in the > property browser. > 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. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property browser
Curtis L. Olson wrote: > Jim Wilson wrote: > >>> From: Josh Babcock >>> >>> Did someone change the property browser so you can't watch the values >>> change in real time? How do I get this back? >>> >>> Josh >>> >> >> >> Which property are you looking at? It has been a very long time, so I >> might be a little off here. IIRC the a property node is only updated >> if the responsible subsystem (e.g. the FDM interface) writes to it. >> If that subsystem does not write to the property then the property >> only gets updated when the property picker does a read which is bound >> to a getter in the responsible subsystem. >> >> My guess is something changed in the subsystem you want data from, >> probably by someone trying to save cpu cycles. >> >> BTW, if this is what has happened, developers should note that the >> flightgear will in many cases (probably most cases) run FASTER if the >> subsystem that owns a property updates it once every frame. >> >> Of course there might be a bug in the latest property system >> work...but the code I have, which is fairly recent, still shows some >> real time updates in the property picker. >> >> > > As I understand it, here is how things have always worked. Properties > that are "tied" to C++ variables don't update automatically. You can > click on the "." at the top to "refresh" the values. Properties that > exist soley within the property system will update "live" in the > property browser. > > Regards, > > Curt. > Yeah, I guess I'm just used to looking at stuff that gets constantly updated. Anyway, I figured it out by just tyeing objects to properties by trial and error. It's all sorted out now. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property browser
Jim Wilson wrote: From: Josh Babcock Did someone change the property browser so you can't watch the values change in real time? How do I get this back? Josh Which property are you looking at? It has been a very long time, so I might be a little off here. IIRC the a property node is only updated if the responsible subsystem (e.g. the FDM interface) writes to it. If that subsystem does not write to the property then the property only gets updated when the property picker does a read which is bound to a getter in the responsible subsystem. My guess is something changed in the subsystem you want data from, probably by someone trying to save cpu cycles. BTW, if this is what has happened, developers should note that the flightgear will in many cases (probably most cases) run FASTER if the subsystem that owns a property updates it once every frame. Of course there might be a bug in the latest property system work...but the code I have, which is fairly recent, still shows some real time updates in the property picker. As I understand it, here is how things have always worked. Properties that are "tied" to C++ variables don't update automatically. You can click on the "." at the top to "refresh" the values. Properties that exist soley within the property system will update "live" in the property browser. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property browser
> From: Josh Babcock > > Did someone change the property browser so you can't watch the values > change in real time? How do I get this back? > > Josh Which property are you looking at? It has been a very long time, so I might be a little off here. IIRC the a property node is only updated if the responsible subsystem (e.g. the FDM interface) writes to it. If that subsystem does not write to the property then the property only gets updated when the property picker does a read which is bound to a getter in the responsible subsystem. My guess is something changed in the subsystem you want data from, probably by someone trying to save cpu cycles. BTW, if this is what has happened, developers should note that the flightgear will in many cases (probably most cases) run FASTER if the subsystem that owns a property updates it once every frame. Of course there might be a bug in the latest property system work...but the code I have, which is fairly recent, still shows some real time updates in the property picker. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] property browser
Did someone change the property browser so you can't watch the values change in real time? How do I get this back? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Property browser bugs
I'm debugging the property browsers. Currently they don't handle indexing properly:
multiple instances of /input/mice/mouse/mode[0]/button/ are shown without indices
because the buttons are numbered 2,3,4 but the test it uses is "Is there a child of
this name with index 1?". Clicking on any of them causes a seg-fault because no such
node (with implied index zero) exists.
I propose to change it to display the index if the index is non-zero OR it has
siblings with the same name (i.e. if index!=0 or there are two or more different
indices).
I also want to factor out this code from FG's telnet interface, FG's property picker,
and SGPropertyNode::getPath which all try to do the same thing. Proposal:
/**
* Return "name[index]", or just "name" if 'simplify' is true and
* the index is 0 and there are no siblings with the same name.
*/
string
SGPropertyNode::getPrettyName(bool simplify) const;
("PrettyName" is a horrible name. Suggestions?)
This seems an appropriate addition because the class already contains the ability to
parse such a string (name with optional index) in getNode(const char * relative_path,
...) and to generate one as a complete path, but not yet to generate one as a single
path component.
While investigating, I found that SGPropertyNode::getPath returns a (char *) pointer
to the character data of a string on its stack, i.e. to undefined memory after it
returns. I remember someone was changing strings to char* for efficiency. Perhaps
this bug was introduced then. I'll include a patch for it with my eventual patch for
the above, unless someone beats me to it. I don't think it affects any existing
callers: they all want a string anyway.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
