Re: [Flightgear-devel] FlightGear Usability
On Sun, Sep 2, 2012 at 3:07 PM, Gijs de Rooy wrote: This is now checked in as the new Joystick Configuration item under the Help menu, which replaces the Joystick Information dialog. I think you forgot to add it to the menu? Whoops. You are correct. I'll correct that when I get the chance - hopefully this evening. While the config dialog is quite neat, and allows users to configure their joysticks, it's still not as good as having a pre-existing set of bindings. Given that it is much easier for users to generate bindings, it would be great to streamline the process for submitting them to git. At a simple level, we could set up an email alias (joysti...@flightgear.org) and have a volunteer check them for suitability and either add the missing name to an existing set of bindings, or check in the binding file if appropriate. Curt - would you be happy to create such an alias? Anyone interested in handling the xml files? If not, I'll do it. I can then update the dialog to ask people to email them to joysti...@flightgear.org if creating a completely new set of bindings. (A more advanced solution would be to have a way for users to submit joysticks bindings from in-sim, but that's a bit more or a faff and open for abuse - it'd be far too easy to press the button by mistake or out of malice) -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
Hi Stuart, This is now checked in as the new Joystick Configuration item under the Help menu, which replaces the Joystick Information dialog. I think you forgot to add it to the menu? I was able to open the dialog via fgcommand, and from what I've tested so far (a very quick test with a simple joystick), it works really well. Well done, this is truly an improvement in usability! Gijs -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
On Sat, Aug 11, 2012 at 9:40 PM, Stuart Buchanan wrote: 2) Joystick configuration. All of the people reading this list are more than competent to write their own joystick XML config file, but it's something that I see huge numbers of posts about on the forum, from people who do not have enough knowledge to edit an XML file. I'm now looking into whether we could configure joysticks within FG itself. My aim is a UI to allow users to change bindings on-the-fly and save the results. This is now checked in as the new Joystick Configuration item under the Help menu, which replaces the Joystick Information dialog. This dialog allows you to see what each of your axes and buttons do, plus reconfigure your joystick in-sim with immediate feedback. Updated joystick configuration files are written on-the-fly to $FG_HOME/Input/Joystick/, which is now read from by FG when the Input Subsystem is reloaded. The dialog re-loads the input, so your changes take effect immediately. If you have some more complicated bindings, you should be able to retain them by selecting Custom from the axis or button selector, but this has had limited testing, and I suspect needs a bit more work to become robust. I've also got a bit more work to do adding instructions, and possibly a deadband option, but the function is basically complete. Feedback is welcome as always. I've intentionally limited the set of axes and buttons that can be configured to avoid over-loading new users. If you feel there are important bindings missing, please let me know. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
On 12 Aug 2012, at 20:44, Martin Spott wrote: But it's not an either/or. There could be an FGCom binary that uses the same code as the built-in FGCom. Which environment would be set up to build this separate binary ? The fgfs one, but I don't think that's a particularly onerous requirement to build fgcom. I can't imagine there's a large use case of people who really want to build fgcom standalone, but haven't already built fgfs from source. I do absolutely agree there are reasons to keep a separate /binary/, to run on a separate machines or similar, as an option (as we do for terrasync), but again for a large number of users the easiest solution would be an 'in process' one in terms of setup, configuration - and the easiest way to achieve that is to make the (tiny) amount of fgcom code live in the fgfs source tree. Anyway, it's only an idea, and not one I have time to work on in the short term :) James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
On Sun, Aug 12, 2012 at 4:48 PM, James Turner wrote: On 11 Aug 2012, at 22:52, Martin Spott wrote: 3) Scenery. Terrasync is now built into FG, and we have nice UI to configure it in-sim. However, it still requires users to set up a separate directory and configure FG_SCENERY before it can be used. It would be great if the standard installers created an $FG_ROOT/WorldScenery directory with the appropriate permissions, and added it to $FG_SCENERY by default. As far as I can tell, the value of /sim/terrasync/scenery-dir was already supposed to be added to the Scenery path, but I don't know at which priority. Right, this is all automatic now - has been since before 2.6 I think. At least on Mac I set a 'correct' directory - in Library/Application Support/FlightGear/Terrasync. Of course this is only a default, but for most users it's enough. That's great. I will test the windows release candidate to see if that is the case there as well. Usability was the main reason for making terrasync be available as in-process option, and I'm strongly considering doing the same thing for fgcom, although that has a few extra complications. BTW, usability is also the reason I made the network options configurable inside the sim, and have been making more subsystems support a clean reset, so that it's possible to sanely control more behaviours with direct results in the sim. I'm a big fan of both of these changes. I very much like the idea of in-sim FGCom, though we should be prepared for the default frequency at KSFO becoming as congested as the in-sim chat! Of course, with an integrated FGCom, the MP chat function becomes much less relevant. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
James Turner wrote: On 12 Aug 2012, at 20:44, Martin Spott wrote: But it's not an either/or. There could be an FGCom binary that uses the same code as the built-in FGCom. Which environment would be set up to build this separate binary ? The fgfs one, but I don't think that's a particularly onerous requirement to build fgcom. No ? FGCom is a perfect match for BeagleBoard-style computers and I know this actually had been one of the development goals, so you could have your radio comms in a neat interface box, no matter which hardware is running FlightGear. As a preparatory step, if you're really planning to shift FGCom into FG, then it's probably worth considering the 'cost' of porting FlightGear, at least those parts of the build system which would be required to build FGCom, to a stripped-down Linux on ARM ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
On 11 Aug 2012, at 22:52, Martin Spott wrote: 3) Scenery. Terrasync is now built into FG, and we have nice UI to configure it in-sim. However, it still requires users to set up a separate directory and configure FG_SCENERY before it can be used. It would be great if the standard installers created an $FG_ROOT/WorldScenery directory with the appropriate permissions, and added it to $FG_SCENERY by default. As far as I can tell, the value of /sim/terrasync/scenery-dir was already supposed to be added to the Scenery path, but I don't know at which priority. Right, this is all automatic now - has been since before 2.6 I think. At least on Mac I set a 'correct' directory - in Library/Application Support/FlightGear/Terrasync. Of course this is only a default, but for most users it's enough. If there's bugs / edge-cases that are not working, please report them and they should be fixable, possibly with a couple of extra configuration options. Usability was the main reason for making terrasync be available as in-process option, and I'm strongly considering doing the same thing for fgcom, although that has a few extra complications. BTW, usability is also the reason I made the network options configurable inside the sim, and have been making more subsystems support a clean reset, so that it's possible to sanely control more behaviours with direct results in the sim. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
James Turner wrote: Usability was the main reason for making terrasync be available as in-process option, and I'm strongly considering doing the same thing for fgcom, although that has a few extra complications. Whereas there's little use of TerraSync without the FG flight sim, there are plausible usage scenarios for FGCom _without_ FlightGear, let's say for ATC. Therefore, while it makes sense to package FGCom alongside with FlightGear for the releases, I'm having mixed feelings about incorporating FGCom into FlightGear core because this would either: a) require to bear all the ballast of FG even if the only thing you'd like to have is FGCom, if FGCom development moves into FG or b) carry the risk of FGCom-in-FG diverge from standalone FGCom. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
On Sunday 12 August 2012 16:07:18 Martin Spott wrote: Whereas there's little use of TerraSync without the FG flight sim, there are plausible usage scenarios for FGCom _without_ FlightGear, let's say for ATC. Therefore, while it makes sense to package FGCom alongside with FlightGear for the releases, I'm having mixed feelings about incorporating FGCom into FlightGear core because this would either: a) require to bear all the ballast of FG even if the only thing you'd like to have is FGCom, if FGCom development moves into FG or b) carry the risk of FGCom-in-FG diverge from standalone FGCom. But it's not an either/or. There could be an FGCom binary that uses the same code as the built-in FGCom. Stefan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
Hi James Am 12.08.2012 um 17:48 schrieb James Turner zakal...@mac.com: On 11 Aug 2012, at 22:52, Martin Spott wrote: 3) Scenery. Terrasync is now built into FG, and we have nice UI to configure it in-sim. However, it still requires users to set up a separate directory and configure FG_SCENERY before it can be used. It would be great if the standard installers created an $FG_ROOT/WorldScenery directory with the appropriate permissions, and added it to $FG_SCENERY by default. As far as I can tell, the value of /sim/terrasync/scenery-dir was already supposed to be added to the Scenery path, but I don't know at which priority. Right, this is all automatic now - has been since before 2.6 I think. At least on Mac I set a 'correct' directory - in Library/Application Support/FlightGear/Terrasync. Of course this is only a default, but for most users it's enough. This is one of the 'correct' places of course. With FGx I put this folder (which I do not name terrasync, I create a folder TerrasyncScenery or TerrasyncData) into Users/Shared by default because of different reasons. One reason is that for the common user the Library Folder is hidden by default now on osx, the other reason is wanted to have an easy shareable place for different machines, so I don't need to terrasync for every machine. Because the Application Support directory is hidden by default I fear there will be some other posts in the forums soon where is my terrasynced scenery, but maybe it's better to have a correct place then my not-so-correct FGx way for osx ;-) Do for consistency reasons it might be good to follow your changes here. Thanks, Yves If there's bugs / edge-cases that are not working, please report them and they should be fixable, possibly with a couple of extra configuration options. Usability was the main reason for making terrasync be available as in-process option, and I'm strongly considering doing the same thing for fgcom, although that has a few extra complications. BTW, usability is also the reason I made the network options configurable inside the sim, and have been making more subsystems support a clean reset, so that it's possible to sanely control more behaviours with direct results in the sim. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
Stefan Seifert wrote: On Sunday 12 August 2012 16:07:18 Martin Spott wrote: Whereas there's little use of TerraSync without the FG flight sim, there are plausible usage scenarios for FGCom _without_ FlightGear, let's say for ATC. Therefore, while it makes sense to package FGCom alongside with FlightGear for the releases, I'm having mixed feelings about incorporating FGCom into FlightGear core because this would either: a) require to bear all the ballast of FG even if the only thing you'd like to have is FGCom, if FGCom development moves into FG or b) carry the risk of FGCom-in-FG diverge from standalone FGCom. But it's not an either/or. There could be an FGCom binary that uses the same code as the built-in FGCom. Which environment would be set up to build this separate binary ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
Stuart Buchanan wrote: 3) Scenery. Terrasync is now built into FG, and we have nice UI to configure it in-sim. However, it still requires users to set up a separate directory and configure FG_SCENERY before it can be used. It would be great if the standard installers created an $FG_ROOT/WorldScenery directory with the appropriate permissions, and added it to $FG_SCENERY by default. As far as I can tell, the value of /sim/terrasync/scenery-dir was already supposed to be added to the Scenery path, but I don't know at which priority. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
