From: Alex P. <ale...@ie...> - 2001-06-20 01:37:41
|
A slightly irrelevant historical comment ... When Curt commented that he REALLY wanted to have PLIB 1.4 available for FGFS, he gave the specific example of the sound library upgrade. This upgrade includes a serious bug fix, for which there is an unreliable workaround, and a feature addition, which bypasses the 3 simultaneous sound limit. The latter was a reference to the patch I had submitted to Steve many months ago, early in the year, which never appeared in the PLIB cvs tree. When I resubmitted the files recently, it was already after the feature cutoff, so it didn't make it into 1.4 and thus is not relevant to FGFS. Subsequently, I requested that the new function call be included (and stubbed) for 1.4 so that there would be simpler compatibility from 1.5 to 1.4 users. This has not been done, so that FGFS is unable to even invoke the function for people who (in the next few months) choose to use plib from cvs. As a result, at this time, I _personally_ gain no benefit from using plib 1.4 with fgfs 0.7.7 compared to 1.2 but note that I'm not speaking for the visual modelling people who may want the new ssg feature set. |
From: <ji...@ke...> - 2001-06-29 21:10:32
|
Does anyone know if property-swap is supposed to work now? It fails with the following code in the keyboard.xml bindings: <key n="86"> <name>V</name> <desc>Swap Panel</desc> <binding> <command>property-swap</command> <property[0]>/sim/panel/path</property[0]> <property[1]>/sim/panel2/path</property[1]> </binding> </key> Yes, the /sim/panel2/path is there. Was thinking about adding a panel-swap command anyway, so that one keystroke could swap and load the second panel. Also might switch the key to "s". Just wondering if this should be working before i dig into the simgear stuff looking for the problem. Jim |
From: John C. <j4s...@ro...> - 2001-06-29 21:41:24
|
What you want to do there is <property[0]>/sim/panel/path=panel.xml</property[0]> <property[1]>/sim/panel/path=minipanel.xml</property[1]> You may or may not need to do shift+F3 to refresh the tile cache, I'm not sure about that. On Fri, 29 Jun 2001 ji...@ke... wrote: > Does anyone know if property-swap is supposed to work now? It fails with > the following code in the keyboard.xml bindings: > > <key n="86"> > <name>V</name> > <desc>Swap Panel</desc> > <binding> > <command>property-swap</command> > <property[0]>/sim/panel/path</property[0]> > <property[1]>/sim/panel2/path</property[1]> > </binding> > </key> > > Yes, the /sim/panel2/path is there. > > Was thinking about adding a panel-swap command anyway, so that one > keystroke could swap and load the second panel. Also might switch the > key to "s". Just wondering if this should be working before i dig > into the simgear stuff looking for the problem. > > Jim > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: <ji...@ke...> - 2001-06-30 00:20:07
|
Hmmmm...actually looking at the fg_commands.cxx that doesn't sound quite right. I did discover that you can bind multiple commands in sequence, so binding the panel-load after the value is swapped should work. Still working on the issue. I think I've got something else wrong with the xml and just not seeing the obvious. Jim John Check <j4s...@ro...> said: > What you want to do there is > > <property[0]>/sim/panel/path=panel.xml</property[0]> > <property[1]>/sim/panel/path=minipanel.xml</property[1]> > > You may or may not need to do shift+F3 to refresh > the tile cache, I'm not sure about that. > > > On Fri, 29 Jun 2001 ji...@ke... wrote: > > > Does anyone know if property-swap is supposed to work now? It fails with > > the following code in the keyboard.xml bindings: > > > > <key n="86"> > > <name>V</name> > > <desc>Swap Panel</desc> > > <binding> > > <command>property-swap</command> > > <property[0]>/sim/panel/path</property[0]> > > <property[1]>/sim/panel2/path</property[1]> > > </binding> > > </key> > > > > Yes, the /sim/panel2/path is there. > > > > Was thinking about adding a panel-swap command anyway, so that one > > keystroke could swap and load the second panel. Also might switch the > > key to "s". Just wondering if this should be working before i dig > > into the simgear stuff looking for the problem. > > > > Jim > > > > > > _______________________________________________ > > Flightgear-devel mailing list > > Fli...@li... > > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- |
From: John C. <j4s...@ro...> - 2001-06-30 02:07:40
|
When you have it working please let me see what it's supposed to be so I can fix the doco On Sat, 30 Jun 2001 ji...@ke... wrote: > Hmmmm...actually looking at the fg_commands.cxx that doesn't sound quite > right. I did discover that you can bind multiple commands in sequence, > so binding the panel-load after the value is swapped should work. > > Still working on the issue. I think I've got something else wrong with > the xml and just not seeing the obvious. > > Jim > > > John Check <j4s...@ro...> said: > > > What you want to do there is > > > > <property[0]>/sim/panel/path=panel.xml</property[0]> > > <property[1]>/sim/panel/path=minipanel.xml</property[1]> > > > > You may or may not need to do shift+F3 to refresh > > the tile cache, I'm not sure about that. > > > > > > On Fri, 29 Jun 2001 ji...@ke... wrote: > > > > > Does anyone know if property-swap is supposed to work now? It fails with > > > the following code in the keyboard.xml bindings: > > > > > > <key n="86"> > > > <name>V</name> > > > <desc>Swap Panel</desc> > > > <binding> > > > <command>property-swap</command> > > > <property[0]>/sim/panel/path</property[0]> > > > <property[1]>/sim/panel2/path</property[1]> > > > </binding> > > > </key> > > > > > > Yes, the /sim/panel2/path is there. > > > > > > Was thinking about adding a panel-swap command anyway, so that one > > > keystroke could swap and load the second panel. Also might switch the > > > key to "s". Just wondering if this should be working before i dig > > > into the simgear stuff looking for the problem. > > > > > > Jim > > > > > > > > > _______________________________________________ > > > Flightgear-devel mailing list > > > Fli...@li... > > > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > > > > > _______________________________________________ > > Flightgear-devel mailing list > > Fli...@li... > > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > > -- > > > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: David M. <da...@me...> - 2001-06-30 01:22:50
|
ji...@ke... writes: > Does anyone know if property-swap is supposed to work now? It fails with > the following code in the keyboard.xml bindings: > > <key n="86"> > <name>V</name> > <desc>Swap Panel</desc> > <binding> > <command>property-swap</command> > <property[0]>/sim/panel/path</property[0]> > <property[1]>/sim/panel2/path</property[1]> > </binding> > </key> That's not the right syntax for XML. Try <property n="0">...</property> <property n="1">...</property> All the best, David -- David Megginson da...@me... |
From: John C. <j4s...@ro...> - 2001-06-30 02:06:14
|
David, The way I have it in the readme is <property[0]> Thats a direct cut/paste from your email describing things. I'll change it. If you could have a look at the new readme and see what else is inaccurate, I'd much appreciate it. TTYL J On Fri, 29 Jun 2001, David Megginson wrote: > ji...@ke... writes: > > > Does anyone know if property-swap is supposed to work now? It fails with > > the following code in the keyboard.xml bindings: > > > > <key n="86"> > > <name>V</name> > > <desc>Swap Panel</desc> > > <binding> > > <command>property-swap</command> > > <property[0]>/sim/panel/path</property[0]> > > <property[1]>/sim/panel2/path</property[1]> > > </binding> > > </key> > > That's not the right syntax for XML. Try > > <property n="0">...</property> > <property n="1">...</property> > > > All the best, > > > David > > -- > David Megginson > da...@me... > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: David M. <da...@me...> - 2001-06-30 02:47:05
|
John Check writes: n > The way I have it in the readme is <property[0]> > Thats a direct cut/paste from your email describing things. Here's what I found in my sent box: null exit view-cycle screen-capture property-toggle (args: property) property-assign (args: property, value) property-adjust (args: property, step) property-swap (args: property[0], property[1]) property-scale (args: property, offset, factor) In other words, --prop:/input/js[0]/button[0]/binding/command=property-swap --prop:/input/js[0]/button[0]/binding/property[0]=/foo --prop:/input/js[0]/button[0]/binding/property[1]=/bar > I'll change it. If you could have a look at the new readme and see > what else is inaccurate, I'd much appreciate it. Thanks. That's probably just an anomaly, but I'll try to take a peek this weekend. All the best, David -- David Megginson da...@me... |
From: John C. <j4s...@ro...> - 2001-06-30 03:23:51
|
On Fri, 29 Jun 2001, David Megginson wrote: > John Check writes: > n > > The way I have it in the readme is <property[0]> > > Thats a direct cut/paste from your email describing things. > > Here's what I found in my sent box: <snip> > property-swap (args: property[0], property[1]) > > In other words, > > --prop:/input/js[0]/button[0]/binding/command=property-swap > --prop:/input/js[0]/button[0]/binding/property[0]=/foo > --prop:/input/js[0]/button[0]/binding/property[1]=/bar Okay, but you didn't say explicitly that as XML the index should be supplied like so <property n="0">. In fact you said that when using XML indices are created automatically, so I assumed we didn't need that. Although you *did* say that the n="0" form is the formal way to write it. I'll clear that up. > > > I'll change it. If you could have a look at the new readme and see > > what else is inaccurate, I'd much appreciate it. > > Thanks. That's probably just an anomaly, but I'll try to take a peek > this weekend. > > > All the best, > > > David > > -- > David Megginson > da...@me... > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: John C. <j4s...@ro...> - 2001-06-30 03:41:08
|
The last paragraph and the example were added. Make sense? Bindings -------- A command may have more than one binding. By default, the examples below use just /binding or <binding>, but /binding[0] or <binding n="0"> is implied. When bindings are specified in XML the indices are created automagically. If you wish to avoid XML you must supply the index number for multiple bindings in your command line formatted options. Multiple properties in a single binding must have the index specified. For example if you build a switch that loads alternate panels the XML form must be written thusly: <command>property-swap</command> <property n="0">/sim/panel/path=foo</property> <property n="1">/sim/panel/path=bar</property> On Fri, 29 Jun 2001, John Check wrote: > > > On Fri, 29 Jun 2001, David Megginson wrote: > > > John Check writes: > > n > > > The way I have it in the readme is <property[0]> > > > Thats a direct cut/paste from your email describing things. > > > > Here's what I found in my sent box: > <snip> > > property-swap (args: property[0], property[1]) > > > > In other words, > > > > --prop:/input/js[0]/button[0]/binding/command=property-swap > > --prop:/input/js[0]/button[0]/binding/property[0]=/foo > > --prop:/input/js[0]/button[0]/binding/property[1]=/bar > > > Okay, but you didn't say explicitly that as XML the index should > be supplied like so <property n="0">. In fact you said that when > using XML indices are created automatically, so I assumed we didn't > need that. Although you *did* say that the n="0" form is the formal > way to write it. I'll clear that up. > > > > > > > I'll change it. If you could have a look at the new readme and see > > > what else is inaccurate, I'd much appreciate it. > > > > Thanks. That's probably just an anomaly, but I'll try to take a peek > > this weekend. > > > > > > All the best, > > > > > > David > > > > -- > > David Megginson > > da...@me... > > > > > > _______________________________________________ > > Flightgear-devel mailing list > > Fli...@li... > > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: David M. <da...@me...> - 2001-06-30 09:35:39
|
John Check writes: > The last paragraph and the example were added. Make sense? > > Bindings > -------- > A command may have more than one binding. By default, the examples below > use just /binding or <binding>, but /binding[0] or <binding n="0"> is > implied. > When bindings are specified in XML the indices are created automagically. > If > you wish to avoid XML you must supply the index number for multiple > bindings > in your command line formatted options. > Multiple properties in a single binding must have the index specified. For > example if you build a switch that loads alternate panels the XML form > must be written thusly: > > <command>property-swap</command> > <property n="0">/sim/panel/path=foo</property> > <property n="1">/sim/panel/path=bar</property> Not quite. First, the '=' sign isn't allowed in a property name, and second, as with the panel code (i.e. <instrument>), you can leave out the indexes and have them generated automatically: <binding> <command>property-swap</command> <property>/foo</property> <property>/bar</property> </binding> This will swap the values of the /foo and /bar properties. I understand now that the original poster wanted to do something different -- cycle through two values for the same property, which is not the intention of this command. I'd like to make a new command to do that, and I think I can generalize it to cycle through n values for the same property, something like this: <binding> <command>property-cycle</command> <property>/sim/fog</property> <value>none</value> <value>fastest</value> <value>nicest</value> </binding> That might not be quite right, though. If the current value is none of the above, how does the command know what to cycle to? Does it always start over? Does it always go to what it thinks is the right position? This needs a bit of thought. All the best, David -- David Megginson da...@me... |
From: <ji...@ke...> - 2001-06-30 12:44:21
|
Actually I had tried all three syntaxes and none of them were working. It seems that for some reason it wouldn't bind to the "V" key. That seems weird. After trying to bind another command to "V" I realized this, and just changed the key. This works: <key n="115"> <name>s</name> <desc>Swap panels.</desc> <binding> <command>property-swap</command> <property>/sim/panel/path</property> <property>/sim/panel2/path</property> </binding> <binding> <desc>Load panel.</desc> <command>panel-load</command> </binding> </key> It also works if you use the n="0", etc sytnax. Is there interest in putting this in the base package along with the default panel? Would a different key be better? I can post a tarball with all the necessary xml included. Not sure if this is a good canditate for a joystick button, but certainly if one wanted to they could bind the same to a button number. Jim David Megginson <da...@me...> said: > John Check writes: > > > The last paragraph and the example were added. Make sense? > > > > Bindings > > -------- > > A command may have more than one binding. By default, the examples below > > use just /binding or <binding>, but /binding[0] or <binding n="0"> is > > implied. > > When bindings are specified in XML the indices are created automagically. > > If > > you wish to avoid XML you must supply the index number for multiple > > bindings > > in your command line formatted options. > > Multiple properties in a single binding must have the index specified. For > > example if you build a switch that loads alternate panels the XML form > > must be written thusly: > > > > <command>property-swap</command> > > <property n="0">/sim/panel/path=foo</property> > > <property n="1">/sim/panel/path=bar</property> > > Not quite. First, the '=' sign isn't allowed in a property name, and > second, as with the panel code (i.e. <instrument>), you can leave out > the indexes and have them generated automatically: > > <binding> > <command>property-swap</command> > <property>/foo</property> > <property>/bar</property> > </binding> > > This will swap the values of the /foo and /bar properties. I > understand now that the original poster wanted to do something > different -- cycle through two values for the same property, which is > not the intention of this command. > > I'd like to make a new command to do that, and I think I can > generalize it to cycle through n values for the same property, > something like this: > > <binding> > <command>property-cycle</command> > <property>/sim/fog</property> > <value>none</value> > <value>fastest</value> > <value>nicest</value> > </binding> > > That might not be quite right, though. If the current value is none > of the above, how does the command know what to cycle to? Does it > always start over? Does it always go to what it thinks is the right > position? > > This needs a bit of thought. > > > All the best, > > > David > > -- > David Megginson > da...@me... > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- |
From: Michael B. <Mic...@ep...> - 2001-07-01 14:55:25
|
Dear Jim, > Not sure if this is a good canditate for a joystick button, but certainly > if one wanted to they could bind the same to a button number. I for one would like that bound to a joystick button, too. Plus, I vote for adding this stuff to the base package. No one else preferrring to have the three upper row instruments (speed/art.horizon/altitude) sid-by side in that order....? Regards, Michael ------------------------------------------------------- Michael Basler, Jena, Germany pm...@ep... http://www.geocities.com/pmb.geo/ |
From: Elad Y. <el...@ee...> - 2001-07-01 15:23:06
|
Hi, (BTW, who is our debian guy ?) Apt system yells at me !! (again...) ;) The flightgear package strictly depends on plib 1.4.x, where the package system updated plib to 1.4.y (where y>x). Should'nt it depend on plib >= 1.4.? and not ==1.4.? ? Thanks, Elady. --------------------- Elad Yarkoni el...@ee... www.ee.bgu.ac.il/~elady Dept. of ECE, BGU, Beer-Sheva, Israel. 972-8-647-2417 |
From: Cameron M. <li...@to...> - 2001-07-01 17:41:49
|
* el...@ee... [2001.07.01 10:30]: > Hi, > > (BTW, who is our debian guy ?) $ dpkg -p flightgear [...] Maintainer: Ove Kaaven <ov...@ar...> [...] > Apt system yells at me !! (again...) ;) > The flightgear package strictly depends > on plib 1.4.x, where the package system > updated plib to 1.4.y (where y>x). > > Should'nt it depend on plib >= 1.4.? and not ==1.4.? ? Yes, you are correct. I'd suggest creating a bug report for the flightgear package. See http://www.debian.org/Bugs/ Also, note that the maintainer builds with pthread support, which is not quite stable yet. Thanks -- Cameron Moore |
From: Elad Y. <el...@ee...> - 2001-07-01 18:10:53
|
Once upon a time, On Sun, 1 Jul 2001, Cameron Moore wrote: > Yes, you are correct. I'd suggest creating a bug report for the > flightgear package. See http://www.debian.org/Bugs/ > > Also, note that the maintainer builds with pthread support, which is not > quite stable yet. Thanks > -- > Cameron Moore > Thanks, i'll try it out (and probably send a bug report... I had so many apt problems, but I still like this system ;)) Elady. --------------------- Elad Yarkoni el...@ee... www.ee.bgu.ac.il/~elady Dept. of ECE, BGU, Beer-Sheva, Israel. 972-8-647-2417 |
From: John C. <j4s...@ro...> - 2001-07-02 20:14:54
|
On Sun, 1 Jul 2001, Michael Basler wrote: > Dear Jim, > > > Not sure if this is a good canditate for a joystick button, but certainly > > if one wanted to they could bind the same to a button number. > > I for one would like that bound to a joystick button, too. Plus, I vote for > adding this stuff to the base package. > > No one else preferrring to have the three upper row instruments > (speed/art.horizon/altitude) sid-by side in that order....? This will be in in some form shortly > > Regards, Michael > > ------------------------------------------------------- > Michael Basler, Jena, Germany > pm...@ep... > http://www.geocities.com/pmb.geo/ > > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: John C. <j4s...@ro...> - 2001-07-02 20:12:08
|
On Sat, 30 Jun 2001 ji...@ke... wrote: > Actually I had tried all three syntaxes and none of them were working. It > seems that for some reason it wouldn't bind to the "V" key. That seems > weird. After trying to bind another command to "V" I realized this, and > just changed the key. This works: I think V may have already been bound. > > <key n="115"> > <name>s</name> > <desc>Swap panels.</desc> > <binding> > <command>property-swap</command> > <property>/sim/panel/path</property> > <property>/sim/panel2/path</property> > </binding> > <binding> > <desc>Load panel.</desc> > <command>panel-load</command> > </binding> > </key> > Yes, this would be a good addition but (he says without trying it first), I think theres a way to write it without /sim/panel2/path. Something about that just looks kludgy, but hey, As long as it works, right? > It also works if you use the n="0", etc sytnax. Is there interest in putting > this in the base package along with the default panel? Would a different key > be better? I can post a tarball with all the necessary xml included. > > Not sure if this is a good canditate for a joystick button, but certainly > if one wanted to they could bind the same to a button number. > Well, I'd vote for joystick because I have a fourth button not doing anything. I think a kbd and a joystick button is the way to go, since that covers all the bases. > Jim > > David Megginson <da...@me...> said: > > > John Check writes: > > > > > The last paragraph and the example were added. Make sense? > > > > > > Bindings > > > -------- > > > A command may have more than one binding. By default, the examples below > > > use just /binding or <binding>, but /binding[0] or <binding n="0"> is > > > implied. > > > When bindings are specified in XML the indices are created automagically. > > > If > > > you wish to avoid XML you must supply the index number for multiple > > > bindings > > > in your command line formatted options. > > > Multiple properties in a single binding must have the index specified. For > > > example if you build a switch that loads alternate panels the XML form > > > must be written thusly: > > > > > > <command>property-swap</command> > > > <property n="0">/sim/panel/path=foo</property> > > > <property n="1">/sim/panel/path=bar</property> > > > > Not quite. First, the '=' sign isn't allowed in a property name, and > > second, as with the panel code (i.e. <instrument>), you can leave out > > the indexes and have them generated automatically: > > > > <binding> > > <command>property-swap</command> > > <property>/foo</property> > > <property>/bar</property> > > </binding> > > > > This will swap the values of the /foo and /bar properties. I > > understand now that the original poster wanted to do something > > different -- cycle through two values for the same property, which is > > not the intention of this command. > > > > I'd like to make a new command to do that, and I think I can > > generalize it to cycle through n values for the same property, > > something like this: > > > > <binding> > > <command>property-cycle</command> > > <property>/sim/fog</property> > > <value>none</value> > > <value>fastest</value> > > <value>nicest</value> > > </binding> > > > > That might not be quite right, though. If the current value is none > > of the above, how does the command know what to cycle to? Does it > > always start over? Does it always go to what it thinks is the right > > position? > > > > This needs a bit of thought. > > > > > > All the best, > > > > > > David > > > > -- > > David Megginson > > da...@me... > > > > > > _______________________________________________ > > Flightgear-devel mailing list > > Fli...@li... > > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > > -- > > > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: John C. <j4s...@ro...> - 2001-07-02 20:03:26
|
On Sat, 30 Jun 2001, David Megginson wrote: > John Check writes: > > > The last paragraph and the example were added. Make sense? > > > > Bindings > > -------- > > A command may have more than one binding. By default, the examples below > > use just /binding or <binding>, but /binding[0] or <binding n="0"> is > > implied. > > When bindings are specified in XML the indices are created automagically. > > If > > you wish to avoid XML you must supply the index number for multiple > > bindings > > in your command line formatted options. > > Multiple properties in a single binding must have the index specified. For > > example if you build a switch that loads alternate panels the XML form > > must be written thusly: > > > > <command>property-swap</command> > > <property n="0">/sim/panel/path=foo</property> > > <property n="1">/sim/panel/path=bar</property> > > Not quite. First, the '=' sign isn't allowed in a property name, and > second, as with the panel code (i.e. <instrument>), you can leave out > the indexes and have them generated automatically: Okay that matches up with my original text. My example, however had the indices specified <property[0]>, etc. I'll try to make it clearer > > <binding> > <command>property-swap</command> > <property>/foo</property> > <property>/bar</property> > </binding> > > This will swap the values of the /foo and /bar properties. I > understand now that the original poster wanted to do something > different -- cycle through two values for the same property, which is > not the intention of this command. > If it works though, why not use it? > I'd like to make a new command to do that, and I think I can > generalize it to cycle through n values for the same property, > something like this: > > <binding> > <command>property-cycle</command> > <property>/sim/fog</property> > <value>none</value> > <value>fastest</value> > <value>nicest</value> > </binding> > > That might not be quite right, though. If the current value is none > of the above, how does the command know what to cycle to? Does it > always start over? Does it always go to what it thinks is the right > position? > > This needs a bit of thought. > > > All the best, > > > David > > -- > David Megginson > da...@me... > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > http://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: <ji...@ke...> - 2001-07-02 22:45:12
|
> > This will swap the values of the /foo and /bar properties. I > understand now that the original poster wanted to do something > different -- cycle through two values for the same property, which is > not the intention of this command. > Well actually what I wanted to do and did, was swap panel/paths...same as cycling two items. > I'd like to make a new command to do that, and I think I can > generalize it to cycle through n values for the same property, > something like this: > Cool. > <binding> > <command>property-cycle</command> > <property>/sim/fog</property> > <value>none</value> > <value>fastest</value> > <value>nicest</value> > </binding> > > That might not be quite right, though. If the current value is none > of the above, how does the command know what to cycle to? Does it > always start over? Does it always go to what it thinks is the right > position? > Maybe a property array (set) would be better? Same as swap only more than two. One could argue that making the first item the "active" item is non-intuitive, in which case we could make things more complex for the sake of xml readability. It is the values that would get cycled though, not the property names, so it seems that making the top on the list (array index 0) the base makes sense. So that on a single cycle shift for a three item array, 2 would be come 1, 1 would be come 0, and 0 would go to the 2 position. The reason that I thought the property-swap was an excellent choice for this application is then actual panel paths to be swapped can be specified on the command line or in the preferences. The choice of "panel2/path" for a property name might not have been too well thought out...perhaps "mini-panel" or alt-panel" would have been better. Jim |