Re: [Flightgear-devel] an idea about dialog-apply command
* Melchior FRANZ -- Sunday 22 February 2009: > To make listeners work as expected the solution is to make *listeners* > work as expected, not to change dialog-apply in a way that makes them > not work as expected. ;-) This should now work. A dialog-apply change might come later. Or not. (I'm still not very happy with it ... and your patch was wrong, too :-). m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command (was: Patch for random system failures)
Hey, * Sébastien MARQUE -- 2/23/2009 11:01 PM: > you can find the patch with, I hope, the correct improvement you asked. Yes, thanks. I do currently not have access to my machine, but will commit in a few days if nobody is quicker. (Temporary variable names with a scope of just three lines should be shorter, but that's now *really* just nitpicking. :-) [change-only listeners] > Be sure that I'll be aware and will recall you of this change if one day > we run into problems, and no-one remembers about it before ;) I seem to remember that the current behavior is even "by design", and not a bug. OK, it probably qualifies as usability or consistency bug. I'll have a look at that, too. > Now I'm going to continue my tries about failures scenarii. The dialog should IMHO be done with XML-embedded Nasal in a regular dialog file, not as pure Nasal code in a *.nas file. This has two advantages: the dialog can easily get reloaded during development, and it doesn't fill up Nasal files with verbose and boring dialog generation code. I find it nicer to get this out of the Nasal files and to keep their focus more on "library" functionality. You can easily use template XML code that you copy and modify. Some dialogs do that already. m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command (was: Patch for random system failures)
Hi Melchior, you can find the patch with, I hope, the correct improvement you asked. I wanted to add that I really agree your point of view: "To make listeners work as expected the solution is to make *listeners* work as expected, not to change dialog-apply in a way that makes them not work as expected.". Be sure that I'll be aware and will recall you of this change if one day we run into problems, and no-one remembers about it before ;) thanks for the interest you had about my suggestion. Now I'm going to continue my tries about failures scenarii. I think I've got some nice ideas about it to make them generic but adaptable (using xml) and improving flight experience. I'll expose you them later as it needs more thinking, and a lot more work. :D best regards seb Melchior FRANZ wrote : * Sébastien MARQUE -- 2/20/2009 1:23 AM: This is not new, it was the case with the precedent gui dialog, and I used a Nasal workaround but not really useful as it disallows to come back to a previous state. I've written a lot of dialogs, the most complicated ones among them, and I don't remember that I ever had to work around this sort of issue. That's one of the reasons why I hesitate when someone asks for a change to make his first(?) dialog work. :-P But anyway. I withdraw my objection and don't mind if someone commits this patch with one improvement: the node value shall not be read twice! That's not so much because of the saved nanoseconds, but mostly because of --trace-read (and style). dialog-apply does then no longer mean copy widget data to the tree, but sync tree with the internal widget state. (dialog-update does still mean *copy*, though ... which is another reason why I'm not thrilled by the change. One more inconsistency to remember ...) But be warned: if we run into problems with this modification, I'll be less hesitant before throwing it out again. ;-) m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Index: src/GUI/dialog.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/dialog.cxx,v retrieving revision 1.115 diff -u -r1.115 dialog.cxx --- src/GUI/dialog.cxx 10 Feb 2009 22:14:13 - 1.115 +++ src/GUI/dialog.cxx 23 Feb 2009 21:26:32 - @@ -437,11 +437,17 @@ case SGPropertyNode::BOOL: case SGPropertyNode::INT: case SGPropertyNode::LONG: -node->setIntValue(object->getIntegerValue()); +int objectintvalue; + objectintvalue = object->getIntegerValue(); + if (node->getIntValue() != objectintvalue) +node->setIntValue(objectintvalue); break; case SGPropertyNode::FLOAT: case SGPropertyNode::DOUBLE: -node->setFloatValue(object->getFloatValue()); +float objectfloatvalue; + objectfloatvalue = object->getFloatValue(); + if (node->getFloatValue() != objectfloatvalue) +node->setFloatValue(objectfloatvalue); break; default: const char *s = object->getStringValue(); -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command
* Melchior FRANZ -- 2/23/2009 10:18 AM: > the node value shall not be read twice Disregard! You aren't doing that, and why should you?! But also don't read the widget value twice, please. :-) m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command (was: Patch for random system failures)
* Sébastien MARQUE -- 2/20/2009 1:23 AM: > This is not new, it was the case with the precedent gui dialog, and I > used a Nasal workaround but not really useful as it disallows to come > back to a previous state. I've written a lot of dialogs, the most complicated ones among them, and I don't remember that I ever had to work around this sort of issue. That's one of the reasons why I hesitate when someone asks for a change to make his first(?) dialog work. :-P But anyway. I withdraw my objection and don't mind if someone commits this patch with one improvement: the node value shall not be read twice! That's not so much because of the saved nanoseconds, but mostly because of --trace-read (and style). dialog-apply does then no longer mean copy widget data to the tree, but sync tree with the internal widget state. (dialog-update does still mean *copy*, though ... which is another reason why I'm not thrilled by the change. One more inconsistency to remember ...) But be warned: if we run into problems with this modification, I'll be less hesitant before throwing it out again. ;-) m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command
* Sébastien MARQUE -- 2/21/2009 7:05 PM: > Yes, I will be obliged to check the value to avoid the instrument fix in > some cases. But as I discover this problem I wanted to try a solution > for every dialog-apply, to make the listeners work as expected, To make listeners work as expected the solution is to make *listeners* work as expected, not to change dialog-apply in a way that makes them not work as expected. ;-) Last time I checked change-only listeners they seemed to work, but either I missed something or they changed behavior. I'll look at that in the next days. I wouldn't hack around a possible bug there in a dialog. Certainly this can wait a few days. My concern with the proposed patch is that it limits functionality in a way that might bite us later. If I write something like the following, then I usually mean it, and don't want fgfs to ignore it: raise signal signal true sim/signals/foo dialog-apply signal And yes, I know that there are other ways to achieve the same. :-) m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command
Yes, I will be obliged to check the value to avoid the instrument fix in some cases. But as I discover this problem I wanted to try a solution for every dialog-apply, to make the listeners work as expected, for future uses, not only the failures system I'm trying to write. If the fix is rejected, that's not a problem for me, but I think we let a problem that can go out again some day... regards seb Csaba Halász a écrit : > On Sat, Feb 21, 2009 at 11:32 AM, Melchior FRANZ wrote: >>setlistener(f ~ "/serviceable", failure[f], 0, 0); >> >> 0 ... trigger on change only > > As I wrote in my other email, this doesn't work as expected. The > listener is triggered initially even if the property doesn't change. > > Sébastien, I think your listeners should check the value of the > property. It might very well happen that a failed instrument is later > fixed, can't it? So the listeners would get triggered again and you'd > have to differentiate between failure and fixing. This would also make > the dialog-apply problem go away. > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command
On Sat, Feb 21, 2009 at 11:32 AM, Melchior FRANZ wrote: > >setlistener(f ~ "/serviceable", failure[f], 0, 0); > > 0 ... trigger on change only As I wrote in my other email, this doesn't work as expected. The listener is triggered initially even if the property doesn't change. Sébastien, I think your listeners should check the value of the property. It might very well happen that a failed instrument is later fixed, can't it? So the listeners would get triggered again and you'd have to differentiate between failure and fixing. This would also make the dialog-apply problem go away. -- Csaba/Jester -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command
Hi Csaba and Melchior,
oops, sorry, I've made a mistake attaching the failures.nas script, but
please believe me that I've first tried
setlistener(f ~ "/serviceable", failure[f], 0, 0);
in order to behave as written in setlistener doc (wiki and globals.nas).
I've just write back to correct listeners args (0 ,0), and unapply patch
but here is the result, I only unchecked Airspeed Indicator, in
Instrument Failures dialog, then use the "Apply" button:
airspeed indicator failure
altimeter failure
turn indicator failure
slip-skid ball failure
heading indicator failure
vertical speed indicator failure
which is not correct. With the small patch applied, correct listeners
args (0, 0) and unchecking Airspeed Indicator again:
airspeed indicator failure
which is correct. I think that it wasn't discovered before (was it?)
because nobody has put several listeners on several properties contained
in one single dialog, or maybe it has no effects (tests on property
value as I've done myself before searching to modify dialog-apply?). I
don't think that the dialog is broken, but for me the dialog-appply
command is.
Reading the code about dialog-apply fgcommand I've seen that every
is copied in dialog.cxx, FGDialog::applyValues
for (unsigned int i = 0; i < _propertyObjects.size(); i++) {
const string &name = _propertyObjects[i]->name;
if (objectName && name != objectName)
continue;
copy_from_pui(_propertyObjects[i]->object,
_propertyObjects[i]->node);
}
independantly of changes, so I thought that it was maybe the reason for
listeners to be fire up.
best regards
seb
Melchior FRANZ a écrit :
> * Melchior FRANZ -- 2/21/2009 9:33 AM:
>> You should have used:
>>
>> setlistener(f ~ "/serviceable", failure[f], 0, 1);
>
> Whoops. Of course, I meant:
>
> setlistener(f ~ "/serviceable", failure[f], 0, 0);
>
>
> The meaning of the first optional argument is:
>
> 0 ... just attach (default)
> 1 ... attach and run initially
>
> and that of the second is:
>
> 0 ... trigger on change only
> 1 ... trigger on writing -- independent of value (default)
> 2 ... trigger on writing to node or children, as well
> as addition and removal of children
>
>
> BTW: We might decide at some point that we only want to dialog-apply
> if values changed, but this needs more consideration, and one broken
> dialog isn't enough reason to convince me. ;-)
>
> BTW2: dialog-{apply,update} should handle an arbitrary number
> of , not just one.
>
> m.
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command
* Melchior FRANZ -- 2/21/2009 9:33 AM:
> You should have used:
>
> setlistener(f ~ "/serviceable", failure[f], 0, 1);
Whoops. Of course, I meant:
setlistener(f ~ "/serviceable", failure[f], 0, 0);
The meaning of the first optional argument is:
0 ... just attach (default)
1 ... attach and run initially
and that of the second is:
0 ... trigger on change only
1 ... trigger on writing -- independent of value (default)
2 ... trigger on writing to node or children, as well
as addition and removal of children
BTW: We might decide at some point that we only want to dialog-apply
if values changed, but this needs more consideration, and one broken
dialog isn't enough reason to convince me. ;-)
BTW2: dialog-{apply,update} should handle an arbitrary number
of , not just one.
m.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command
I object to the proposed change. (Reasons below.) * Sébastien MARQUE -- 2/21/2009 2:39 AM: > In this script you'll find several listeners linked to several > properties that can be modified using instrument-failures.xml or > system-failures.xml. Except that these are *not* change-only listeners. | setlistener(f ~ "/serviceable", failure[f]); You should have used: setlistener(f ~ "/serviceable", failure[f], 0, 1); ... as described on the wiki page about Nasal. But there are two other ways to avoid your problem: - Use on the checkbox and don't apply the whole dialog every time. - Use dialog-apply on selected checkboxes (object-name!): dialog-apply checkbox1 Because (default Nasal-)listeners are *by design* triggered whenever they are written to, and this can be desired behavior (what about applying a signal property multiple times?), and because there are three methods to avoid problems arising from that, I don't think applying the patch would be a good idea. m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command (was: Patch for random system failures)
On Sat, Feb 21, 2009 at 2:39 AM, Sébastien MARQUE wrote: > > no problem. I've attached a nasal script to put in whatever aircraft you > want. In this script you'll find several listeners linked to several > properties that can be modified using instrument-failures.xml or > system-failures.xml. > > Then open the Equipment -> Instrument failures dialog and uncheck Airspeed > Indicator, then Apply, you will see in the terminal that all the listeners > have been triggered, which is not not correct. Hi Sébastien, Thanks for the example, I could reproduce the problem. I have traced it to the FGNasalListener implementation, which doesn't do what I expected it to do :) The inline docs say: // If the fourth, optional argument is set to 0, then the // function is only called when the property node value actually changes. That seems pretty clear to me but apparently on the *first* write event the listener is triggered even if the value hasn't changed. We shall ask Melchior about it, I am sure he knows the logic behind it. -- Csaba/Jester -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command (was: Patch for random system failures)
Hi Csaba,
no problem. I've attached a nasal script to put in whatever aircraft you
want. In this script you'll find several listeners linked to several
properties that can be modified using instrument-failures.xml or
system-failures.xml.
Then open the Equipment -> Instrument failures dialog and uncheck
Airspeed Indicator, then Apply, you will see in the terminal that all
the listeners have been triggered, which is not not correct.
After the patch have been applied, reopen the dialog, uncheck again
airspeed indicator, then you'll find that only the listener linked to
"/instrumentation/airspeed-indicator/serviceable" will be fired, as it
should be.
I've grep'ed in FG sources to find out if copy_from_pui has an other
caller than applyValues but it is not the case, and it is not public
(AFAIK C++ ;)), so I think that the change is quite safe. Anyway you may
think the problem is deeper... in listeners code for example, but my
knowledge about FG sources is not great enough to check in this place :D.
regards
seb
Csaba Halász wrote :
On Fri, Feb 20, 2009 at 8:46 AM, Sébastien MARQUE wrote:
actually I already use a listener that only fires then the value really
change. I've looked in Nasal scripting wiki page and globals.nas to be
sure, and tried the other possible values for the fourth argument of
setlistener, with no more succes, that's why I looked in FG sources. If
changes in sources can't be applied or don't have the expected effects
I've got an other workaround, but it is quite an ugly one.
If the "listeners that only fire on real change" don't work then it is
a bug that should be fixed. Can you give instructions how to reproduce
this problem?
Not that I have anything against your patch, looks harmless enough :)
var init_failures = func {
foreach (var f; keys(failure)) {
#props.globals.getNode(f ~ "/serviceable", 1).setBoolValue(1);
setlistener(f ~ "/serviceable", failure[f]);
}
print("Init failures system... OK");
}
var keep_serviceable = func (s) {
setprop(s ~ "/serviceable", 1);
}
var failure = {
"/instrumentation/airspeed-indicator" : func {
#keep_serviceable("/instrumentation/airspeed-indicator");
props.globals.getNode("/instrumentation/aliases/airspeed").unalias();
print("airspeed indicator failure");
shake_airspeed_indicator();
},
#"/instrumentation/attitude-indicator" : func {
# print("attitude indicator failure");
#},
"/instrumentation/altimeter" : func {
props.globals.getNode("/instrumentation/aliases/altitude").unalias();
print("altimeter failure");
},
"/instrumentation/turn-indicator" : func {
props.globals.getNode("/instrumentation/aliases/turn-rate").unalias();
print("turn indicator failure");
},
"/instrumentation/slip-skid-ball" : func {
props.globals.getNode("/instrumentation/aliases/turn-rate").unalias();
print("slip-skid ball failure");
},
"/instrumentation/heading-indicator" : func {
props.globals.getNode("/instrumentation/aliases/heading").unalias();
print("heading indicator failure");
},
"/instrumentation/vertical-speed-indicator" : func {
props.globals.getNode("/instrumentation/aliases/vertical-speed").unalias();
print("vertical speed indicator failure");
},
"/systems/static" : func {
getprop("/systems/static/serviceable") == 0 or return;
# we still need the calculated values by FG to compute indicated values
keep_serviceable("/systems/static");
props.globals.getNode("/instrumentation/aliases/airspeed").unalias();
props.globals.getNode("/instrumentation/aliases/altitude").unalias();
props.globals.getNode("/instrumentation/aliases/vertical-speed").unalias();
props.globals.getNode("/instrumentation/aliases/vertical-speed").setValue(0.0);
compute_airspeed();
print("static failure");
},
"/systems/pitot" : func {
# FG seems to already compute a correct indicated airspeed
# already for this case
print("pitot failure");
},
"/systems/vacuum" : func {
props.globals.getNode("/instrumentation/aliases/heading").unalias();
print("vacuum failure");
}
};
var internal_airspeed =
props.globals.getNode("/instrumentation/airspeed-indicator/indicated-speed-kt");
var indicated_airpeed =
props.globals.getNode("/instrumentation/aliases/airspeed");
var compute_airspeed = func {
# workaround waiting for better calculation,
# I think it should be dependant of environment pressure (altitude?).
indicated_airpeed.setValue(1.1 * internal_airspeed.getValue());
settimer(compute_airspeed, 0);
}
var shake_airspeed_indicator = func {
indicated_airpeed.setValue((2.5 - (rand() * 5)) +
internal_airspeed.getValue());
settimer(shake_airspeed_indicator, 0.1);
}
--
Re: [Flightgear-devel] an idea about dialog-apply command (was: Patch for random system failures)
On Fri, Feb 20, 2009 at 8:46 AM, Sébastien MARQUE wrote: > > actually I already use a listener that only fires then the value really > change. I've looked in Nasal scripting wiki page and globals.nas to be > sure, and tried the other possible values for the fourth argument of > setlistener, with no more succes, that's why I looked in FG sources. If > changes in sources can't be applied or don't have the expected effects > I've got an other workaround, but it is quite an ugly one. If the "listeners that only fire on real change" don't work then it is a bug that should be fixed. Can you give instructions how to reproduce this problem? Not that I have anything against your patch, looks harmless enough :) -- Csaba/Jester -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command (was: Patch for random system failures)
Hi, attached the patch to apply only the changed values in a dialog box using dialog-apply fgcommand. Now only the listener(s) associated with the changed value are fired. It works fine here, and I think it could be useful to apply it. Thanks a lot regards seb Sébastien MARQUE a écrit : Hi Csaba, actually I already use a listener that only fires then the value really change. I've looked in Nasal scripting wiki page and globals.nas to be sure, and tried the other possible values for the fourth argument of setlistener, with no more succes, that's why I looked in FG sources. If changes in sources can't be applied or don't have the expected effects I've got an other workaround, but it is quite an ugly one. regards seb Csaba Halász wrote : On Fri, Feb 20, 2009 at 1:23 AM, Sébastien MARQUE wrote: Indeed, it seems like the dialog-apply command changes every single property linked to a checkbox causing the listeners set on these properties to be triggered even if the property hadn't be changed by the user. The result is that all instruments or systems which have a listener are triggered, and obviously fail all instruments and systems in my case. You can use a listener that only fires when the value really changes. See the docs for the setlistener function. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Index: src/GUI/dialog.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/dialog.cxx,v retrieving revision 1.115 diff -u -r1.115 dialog.cxx --- src/GUI/dialog.cxx 10 Feb 2009 22:14:13 - 1.115 +++ src/GUI/dialog.cxx 20 Feb 2009 21:14:16 - @@ -437,11 +437,13 @@ case SGPropertyNode::BOOL: case SGPropertyNode::INT: case SGPropertyNode::LONG: -node->setIntValue(object->getIntegerValue()); + if (object->getIntegerValue() != node->getIntValue()) +node->setIntValue(object->getIntegerValue()); break; case SGPropertyNode::FLOAT: case SGPropertyNode::DOUBLE: -node->setFloatValue(object->getFloatValue()); + if (object->getFloatValue() != node->getFloatValue()) +node->setFloatValue(object->getFloatValue()); break; default: const char *s = object->getStringValue(); -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command (was: Patch for random system failures)
Hi Csaba, actually I already use a listener that only fires then the value really change. I've looked in Nasal scripting wiki page and globals.nas to be sure, and tried the other possible values for the fourth argument of setlistener, with no more succes, that's why I looked in FG sources. If changes in sources can't be applied or don't have the expected effects I've got an other workaround, but it is quite an ugly one. regards seb Csaba Halász wrote : > On Fri, Feb 20, 2009 at 1:23 AM, Sébastien MARQUE wrote: >> Indeed, it seems like the dialog-apply command changes every single >> property linked to a checkbox causing the listeners set on these >> properties to be triggered even if the property hadn't be changed by the >> user. The result is that all instruments or systems which have a >> listener are triggered, and obviously fail all instruments and systems >> in my case. > > You can use a listener that only fires when the value really changes. > See the docs for the setlistener function. > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command (was: Patch for random system failures)
On Fri, Feb 20, 2009 at 1:23 AM, Sébastien MARQUE wrote: > > Indeed, it seems like the dialog-apply command changes every single > property linked to a checkbox causing the listeners set on these > properties to be triggered even if the property hadn't be changed by the > user. The result is that all instruments or systems which have a > listener are triggered, and obviously fail all instruments and systems > in my case. You can use a listener that only fires when the value really changes. See the docs for the setlistener function. -- Csaba/Jester -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] an idea about dialog-apply command (was: Patch for random system failures)
Hi all,
I'm still trying to get failures implemented specifically for one
aircraft (before finding a better way for global solution). I've got a
"problem" with the dialogs instrument-failures.xml and
system-failures.xml, using the check boxes.
Indeed, it seems like the dialog-apply command changes every single
property linked to a checkbox causing the listeners set on these
properties to be triggered even if the property hadn't be changed by the
user. The result is that all instruments or systems which have a
listener are triggered, and obviously fail all instruments and systems
in my case.
This is not new, it was the case with the precedent gui dialog, and I
used a Nasal workaround but not really useful as it disallows to come
back to a previous state. So maybe it is time to check this out directly
in FG sources, and find a "solution" for dialog-apply command.
I had a look in $FGSRC/src/GUI/dialog.cxx.
We could do something like the following in copy_from_pui (line 430)
...
switch (node->getType()) {
case SGPropertyNode::BOOL:
case SGPropertyNode::INT:
case SGPropertyNode::LONG:
+++ if (object->getIntegerValue() != node->getIntegerValue())
node->setIntValue(object->getIntegerValue());
break;
case SGPropertyNode::FLOAT:
case SGPropertyNode::DOUBLE:
+++ if (object->getFloatValue() != node->getFloatValue())
node->setFloatValue(object->getFloatValue());
break;
...
copy_from_pui is called from FGDialog::applyValues, itself called from
do_dialog_apply (in Main/fg_commands.cxx).
I don't know if this sounds like an acceptable trick, and if it could
cause side effects. But maybe it could solve the problem of multiple
properties modified, triggering listeners which not have to. What do you
think about this?
btw, using MTBF works fine (as Nasal code changes only the wanted
property) and is a nice tool ;)
hope I've been understandable :)
best regards
seb
Stuart Buchanan wrote :
>
> I believe the current patch is ready for review and inclusion in CVS.
Feedback is obviously very welcome :)
>
> My thanks to John and erobo for their work on this.
>
> -Stuart
>
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An idea
It seems however that version only OSG are not yet really on the agenda. Much will keep a version 0.9.10 or 0.9.11 to see 0.9.1, all using Plib, for still some time. But much would like or will like to have access to planes CVS. Is thus necessary it to prohibit to them simply because they wish to have a stable version. That was right to help those which do not place their planes in the CVS to remain compatible with all the versions and to prepare the future more easily. OSG is really very well, but certainly not yet for immediately. Then to prepare as much most simply possible. The addition of a simple Boolean value in the properties should not surely hustle all the code of FG ;) but the work of the creators of planes except CVS would be simpler and easier to integrate in the future. Now if the idea is bad, I incline myself ;) Best regards. Emmanuel -- BARANGER Emmanuel http://helijah.free.fr http://helijah.free.fr/Pack_3D http://helijah.free.fr/flightgear/flightgear.htm http://helijah.free.fr/flightgear/H4-Hercules.htm http://helijah.free.fr/flightgear/hangar.htm - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An idea...
On jeu 20 septembre 2007, BARANGER Emmanuel wrote: > Hello, > > Can be that I did not find and that that already exists :-[ . But it > would be possible, in the property of FlightGear, to have a flag who > indicates which launched version (Plib or OSG) ? > > Thus, the planes, scenery etc... could be automatically adapted to the > version. > > Something like: > > > > systems/version/plib > false > > > > Best regards. Emmanuel Yeah, which could be a nice answer, to some multi versions models like Catalina. However, which depends on the delay of the delivery of the 0.9.11 release. If the delay is short, and that 0.9.11 release the last with PLib only, that new Property will not be very profitable. Every CVS data being OSG only compatible. Cheers -- Gérard - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] An idea...
Hello, Can be that I did not find and that that already exists :-[ . But it would be possible, in the property of FlightGear, to have a flag who indicates which launched version (Plib or OSG) ? Thus, the planes, scenery etc... could be automatically adapted to the version. Something like: systems/version/plib false Best regards. Emmanuel -- BARANGER Emmanuel http://helijah.free.fr http://helijah.free.fr/Pack_3D http://helijah.free.fr/flightgear/flightgear.htm http://helijah.free.fr/flightgear/H4-Hercules.htm http://helijah.free.fr/flightgear/hangar.htm - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
