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
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
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
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
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
[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
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
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
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
[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
