Board index FlightGear Support Hardware

Just a comment

Joysticks, pedals, monitors.

Re: Just a comment

Postby stuart » Mon Jul 08, 2013 9:29 pm

Hi Guys,

Apologies for not getting more involved in this topic - not enough hours in the day.

I'm very happy if someone wants to expand the Joystick GUI to include advanced features such as modifier keys, and support for arbritary Nasal snippets. I also very much like the idea of re-implementing it in Canvas, as I had to make some design decisions purely on the basis of what was possible through the XML GUI code.

If someone is working on this, it would be good to add support to allow setting of the joystick deadband - this is something that I simply haven't had the time to add.

Finally, one point that I'm sure you will bear in mind: It's critical that it remains easy to use for new users. In particular, I spent some time determining the minimum set of bindings that were really required so that someone programming their joystick for the first time wouldn't be overloaded by a massive list of possible key bindings. It might be worth having an "Advanced bindings" option that enables modifier keys and the more esoteric bindings. For example, my yoke has a slider switch that I use to control the sensitivity of the view movement control. That's really useful for my yoke in particular, but probably doesn't generalize.

Finally, I'm very happy to review any code that people want to submit, though I apologize in advance if it takes me a little time.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Just a comment

Postby macnab » Tue Jul 09, 2013 4:35 am

It's critical that it remains easy to use for new users

Agree totally there. And for doing it in Canvas. And for all buttons to be implemented in a nas file, not the xml file. (Standard axes can stay in the xml file.)

For the axes, along with deadband, power as well. (With a slider in the GUI?)

Maybe the start page with only the basic bindings, and 3 buttons: Basic, Medium and Advanced that change the view?

Something that occurs to me is that once the system is out there people will make requests for bindings that don't exist yet. If these are implemented, unless the people use Git, they will have to wait for a new release to see them. So maybe a system where they can download just the necessary files, which be the GUI and the new glorified version of controls.nas.

To make this work we definitely need to get around the repeatable/non-repeatable limitation first.

I am not volunteering to do the GUI, but I have quite a large selection of nas routines. And I can contribute more of them on request.
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby Hooray » Tue Jul 09, 2013 5:45 am

So maybe a system where they can download just the necessary files, which be the GUI and the new glorified version of controls.nas.

You could provide custom bindings as self-contained PropertyList-encoded XML files with embedded Nasal sections - FlightGear already supports loading PropertyList XML files via network, which is how the multiplayer list is loaded dynamically. In other words, you could take these building blocks and load/share arbitrary stuff via network, including custom joystick bindings.

For details, see: http://wiki.flightgear.org/Howto:Making ... from_Nasal
The tutorial also demonstrates how to use a simple web server (in fact, a single line in python) to serve a FG GUI XML file that shows a FG GUI dialog with a custom message ("Hello World").
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Just a comment

Postby macnab » Tue Jul 09, 2013 6:07 am

@Hooray The problem with this is it is "realtime", for the session only. One could use this method to download the files from the main-menu - FG knows where to put the files, but fiddling the user's download-directory would be a nightmare (and dangerous should the link go down before it is restored to it's old value.)

I was thinking along the lines of a link in a JoystickGUI wiki that takes you to a web-page where you can download just the relevant files, in much the same way as getting the latest Jenkins build.

Of course, computer-literacy becomes a relevant factor, but it would still be trivial compared to teaching them to locate and edit their xml file.

Might I suggest a Support->JoystickGUI sub-forum?
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby Hooray » Tue Jul 09, 2013 6:39 am

macnab wrote in Tue Jul 09, 2013 6:07 am:@Hooray The problem with this is it is "realtime", for the session only. One could use this method to download the files from the main-menu - FG knows where to put the files, but fiddling the user's download-directory would be a nightmare (and dangerous should the link go down before it is restored to it's old value.)


Actually, you could simply use $FG_HOME for that - either by using the "userarchive" attribute on all JS-related snippets, so that they become persistent between sessions (see $FG_HOME/autosave.xml) or by using a custom PropertyList-XML file that stores downloaded snippets and uses a hash to check if they were already downloaded and/or need to be updated. Thus, you would only need to be online when downloading things - later on, everything would be persistent/cached.

I was thinking along the lines of a link in a JoystickGUI wiki that takes you to a web-page where you can download just the relevant files, in much the same way as getting the latest Jenkins build.

take a look at the tutorial that I linked to earlier: it uses the official fgdata repository to dynamically download the latest XML/Nasal stuff - and we've been talking about using such a method for automatically updating the Nasal APIs of the Canvas system. Also, Zakalawe is planning to provide a feature to allow aircraft to be downloaded at runtime using WebDAV (see the wiki)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Just a comment

Postby macnab » Tue Jul 09, 2013 6:42 am

That would make life a lot easier for all.
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby Hooray » Tue Jul 09, 2013 6:46 am

also, by convention, fgdata has usually been considered (and installed) as read-only - especially on "true" multi-user systems, so this should be kept in mind - it simply makes sense to have user-specific stuff in $FG_HOME, i.e. a user-specific directory for application settings. Just look at how TerraSync solves the same problem basically - because it also cannot modify $FG_ROOT, but still needs to download and store tons of data.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Just a comment

Postby macnab » Tue Jul 09, 2013 6:53 am

The library and GUI will have to be put in a read/write folder. It does mean making FG look for it in the correct place - non-standard.
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby Hooray » Tue Jul 09, 2013 7:06 am

macnab wrote in Tue Jul 09, 2013 6:53 am:The library and GUI will have to be put in a read/write folder. It does mean making FG look for it in the correct place - non-standard.


There are a bunch of Nasal wrappers available in io.nas for loading Nasal code from different places, and there are helpers in gui.nas to load GUI dialogs from non-standard places. Keep in mind how we have a bunch of Nasal code and custom GUI dialogs in most aircraft folders, which are also "non-standard" - so that's a no-brainer.


I have forwarded your forum suggestion to the admin, but in the meantime I'd suggest to collect all JS related ideas/feature requests in a dedicated wiki article and see how many volunteers we have to handle different aspects of it: http://wiki.flightgear.org/Improving_the_Joystick_GUI
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Just a comment

Postby macnab » Tue Jul 09, 2013 7:13 am

Got to pop out for a while. When I get back I wall add a paragraph "Thoughts/Ideas" for a start. I will also make a post asking for volunteers, pointing them to the wiki (or add them to the wiki myself, flagged as "offers" and "confirmed."
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby Hooray » Tue Jul 09, 2013 7:18 am

ok, sounds like a plan - I'm finished with the stub for now, so don't worry about editing it now
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Just a comment

Postby Philosopher » Tue Jul 09, 2013 12:19 pm

Ok, I think I can do this (plus I have the advantage of time to do this). I've been collecting notes on this, so thanks guys for all your feedback :). It certainly will have three different modes, but I'm not sure if we really need a distinction between medium/advanced and so I was debating a Philosopher mode :P (which would basically use my library for throttle modes, control_functions, etc. -- quite over-the-top, but I would enjoy it very much). Anyways, I'll see how things turn out.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Just a comment

Postby Philosopher » Wed Jul 10, 2013 2:59 am

Okay, so I got started on a Canvas port of the dialog. I have a basic layout (joystick selector, refresh button, axis list & button to reassign axis), but it doesn't actually work, per se. There's a fair amount of communication through the property tree which I will have to resolve, one major bug with the axis assignment popup (somehow two windows get generated and only one can be deleted, which is really funny because I use the same class and pretty much the same code for the main dialog), but otherwise things are going fine. I've made two changes to the bindings: added a view reset button (which I use constantly) and fix the hat bindings for view direction (it was basically dir+=30 & non-repeatable instead of a smooth slewProp-like binding).

I'm working on it, more progress tomorrow :).
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Just a comment

Postby macnab » Wed Jul 10, 2013 3:41 am

@Philosopher Great. Nice to have progress.
macnab
 
Posts: 886
Joined: Tue Aug 02, 2011 7:20 am
Location: Johannesburg, South Africa
Callsign: ZS-ILH
Version: Git
OS: Win7Pro 64bit SP1

Re: Just a comment

Postby Hooray » Wed Jul 10, 2013 5:25 am

For a "canvas port", you'd probably want to identify required widgets first and then implement them separately, in a re-usable fashion - otherwise, it's going to be some monolithic spaghetti code monster with lots of internal dependencies that aren't stricly needed. I'm not sure which UI issues Stuart was referring to, but PUI is known to be pretty archaic - so if there are certain widgets that would simplify the job, we could just as well create those first.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Hardware

Who is online

Users browsing this forum: No registered users and 14 guests