Sorry I had this project abandoned for a long time (again). I did notice the latest issues and PR filed and I will look at them when I find the time. As usual, I come with more changes after a long hiatus.
This PR mixes several small changes with big changes; the most drastic one is that all settings hardcoded in the JavaScript side are now moved to the CSS side, along with the layouts and their style options. This allows us to potentially have different settings for different controls and/or different layouts.
Here is an excerpt from current base.css. Currently it's way too verbose and could possibly be better organized:
.control { /* Do not modify this line: */ z-index: 2;
/* Default Yoke configuration follows.
* Times can be given as milliseconds (8ms) or seconds (8s).
* Boolean options can be given as yes/true or no/none/false.
* Numbers can be given as-is, or as percentages.
* Most options may be disabled setting all values to 0/no/none/false. */
/* The area that a joystick or knob covers is divided in 8 octants.
* Yoke can vibrate when the finger changes octants. */
--vibrate-on-octant-edge: 20ms;
/* Vibration pattern when the finger is over the joystick edge.
* The first value is the vibration time,
* the second value is the relaxation time. */
--vibrate-on-edge: 9ms 11ms;
/* If `yes` or `true`, the vibration becomes stronger the
* farther the joystick is pushed beyond its borders. */
--vibrate-proportionally-to-distance: no;
/* Tactile feedback when a control "clicks", for example:
* thumbstick is pressed down to simulate L3/R3 button;
* a button or a D-pad leg is clicked.
* (Yoke never vibrates on finger release to avoid crosstalk). */
--vibrate-on-click: 40ms;
/* Tactile feedback when a knob or joystick is touched: */
--vibrate-on-touch: 40ms;
/* Width and height of a central deadzone:
* (round or square, depending on the shape of the control itself). */
--center-deadzone: 10% 10%;
/* Calibration for pressure-sensitive controls.
* The first value is the minimum pressure that will engage it,
* while the second value is the pressure that will saturate it.
* The meaning for joysticks is slightly different; see below. */
--force-thresholds: 10% 40%;
/* The controller always is centered in the area assigned to it.
* Some controls can have different shapes:
* - rectangle (covers the whole area);
* - square (covers the maximum square that fits in the area)
* - ellipse (whose axes match the area's width and height)
* - circle (covers the maximum circle that fits in the area)
* Not all of the controllers accept all shapes. Some of them will
* be rectangular in spite of this setting: */
--shape: rectangle;
}
/* Variables after this line override the defaults above for specific controls.
* Some variables only are defined for one specific type of control (like D-pads.) */
/* Joysticks */
.joystick {
--vibrate-on-click: 45ms;
/* Calibration for finger pressure.
* On joysticks, the first value has no effect yet.
* The second value is only used on joysticks with a L3/R3 button below,
* and determines at which pressure is it considered pressed. */
--force-thresholds: 10% 20%;
/* Determines the shape of both the joystick itself and the central deadzone, if any.
* If circle or ellipse, specify only one percentage (from center to edge).
* If rectangle or square, specify the percentage per axis */
--shape: rectangle;
--center-deadzone: 10% 10%;
}
This also allows us to fine-tune the behaviour of joysticks. For the moment, default options for the joysticks are:
s, rectangular joysticks with a lineal, scaled dead zone per axis, and a joystick which doesn't auto-centre when released
j, same as above, but the joystick auto-centres.
t, same as above, but the joystick is now round and the dead zone is radial. The controller will start to vibrate and the input will be rescaled when the joystick goes beyond this round border.
These defaults can be changed through the options --shape and --center-deadzone. In the future, I will probably add a --sticky flag and extend the --shape parameter to more types of control (for example, to better control the aesthetics of buttons).
Also, controls are reported in a different order; this avoids unexpected behaviours such as the first and more important button being under the thumb joysticks by default. (All programs that depend on Yoke, and some programs on Linux can't look at the event codes in events.py.)
In a future update, I can add a flag to yoke so that the D-Pad will be reported as a hat switch. This should improve the auto-detection of the D-Pad in both OSs (because, again, programs cannot or will not notice the BTN_DPAD scancodes). This still requires some testing and changes that would conflict with PR #62 by JingMatrix, so I decided to postpone working on this.
Sorry I had this project abandoned for a long time (again). I did notice the latest issues and PR filed and I will look at them when I find the time. As usual, I come with more changes after a long hiatus.
This PR mixes several small changes with big changes; the most drastic one is that all settings hardcoded in the JavaScript side are now moved to the CSS side, along with the layouts and their style options. This allows us to potentially have different settings for different controls and/or different layouts.
Here is an excerpt from current
base.css. Currently it's way too verbose and could possibly be better organized:This also allows us to fine-tune the behaviour of joysticks. For the moment, default options for the joysticks are:
s, rectangular joysticks with a lineal, scaled dead zone per axis, and a joystick which doesn't auto-centre when releasedj, same as above, but the joystick auto-centres.t, same as above, but the joystick is now round and the dead zone is radial. The controller will start to vibrate and the input will be rescaled when the joystick goes beyond this round border.These defaults can be changed through the options
--shapeand--center-deadzone. In the future, I will probably add a--stickyflag and extend the--shapeparameter to more types of control (for example, to better control the aesthetics of buttons).Also, controls are reported in a different order; this avoids unexpected behaviours such as the first and more important button being under the thumb joysticks by default. (All programs that depend on Yoke, and some programs on Linux can't look at the event codes in
events.py.)In a future update, I can add a flag to
yokeso that the D-Pad will be reported as a hat switch. This should improve the auto-detection of the D-Pad in both OSs (because, again, programs cannot or will not notice the BTN_DPAD scancodes). This still requires some testing and changes that would conflict with PR #62 by JingMatrix, so I decided to postpone working on this.