I certainly empathize with migraines...they're brutal and can be completely debilitating.
Honestly I'm not shocked about the required pressure. It wasn't too hard, but I also don't know what kind of pressure (or lack thereof) requirements I was working with.
And you're correct, there's absolutely nothing I can do about that; it's in the hardware of the trackpad itself, not something we can configure beyond whenever it does start to report a touch. I did try to disable the tap mode in the device, but it didn't seem to do anything. I was hoping it would result in it simply reporting the touch/coords which I could then use code instead to report a tap (e.g. received touch input, then no touch input and the distance was below a threshold, so send a click).
I honestly think it has to do with the capacitance, like if I try to tap with the tip of my index finger, which has some callus (e.g. very low in moisture) I have to press fairly hard. But if I use the side of my thumb (just below beginning of thumbnail, left outer edge) it's extremely sensitive to detecting that - I can just barely feel the surface of the touchpad and it reports the touch. I don't know if that even helps us in any way, but is a valid observation about the issue. It might also be the amount of surface area as that results in a wider area touching the pad which perhaps aids in triggering the event and determining and center location to use as the point touched. Maybe it's intentional to prevent false events - but whatever it is, there's just nothing that can be done about that as it's in the hardware of the trackpad itself.
Edit: Focus on this next paragraph, some of the above may not be relevantBut you can try checking the Show Serial Data Input and see what's showing up when you're moving/trying to tap. It seems that if it is detecting movement (thus detecting your thumb) fine, it should also detect tapping. It might be the issue is that it's detecting movement or something instead of a tap. That's something we could work with within the app. Like imagine you're trying to tap, but the pressure is very minimal and in the action of attempting to tap your thumb is actually sliding a little. If the touchpad detects movement, it won't report a tap just coordinates. If that's the case, the app would be receiving something in the format
X,X,X|F instead of a detected tap, which would look like
X,X,X|G. I can absolutely handle that in the app's code. In fact, testing that theory on the touchpad just now, tapping with the slightest slide doesn't send the
G (gesture - tap), only the
F (finger present) - I can even do it in such a way that it reports F and doesn't even move the mouse as it didn't think there was far enough finger movement to send multiple coordinates.
So definitely do that first thing, check that box and see what's streaming in when you try a tap. If you're seeing anything show up, then it's a solution which can be handled in the app by looking for "G" events like it does now, but also tracking the incoming "F" events and using distance/timing thresholds to translate to a tap/click (which is basically what the trackpad hardware also does internally) instead of a movement. I also notice that if the tap isn't fast enough, the trackpad will just report a single F event instead of G for tap. So yeah, let me know what you see when you get around to checking it out.
(paragraph below was typed before some edits/theory craft above, but leaving it anyway)When I came across that other touchpad dev kit (
https://www.cirque.com/gen4-trackpad-dev-kit), I
really wanted to just order it and scrap everything I'd done thus far, but I decided that would be hasty and I didn't want to be jumping from one shiny thing to another, never producing any results at all. It's a crappy situation because we won't know how it will detect your thumb without having the hardware first in your possession. But these kits don't necessarily show up ready to just test your thumb on it. You'd have to download the Arduino IDE, their source code, compile it to the board, run, use the serial monitor (Arduino IDE) to issue it commands then see the output. From researching this unit and the source code, though, it
looks like it would actually do that fairly out of the box. The main loop looks like it just continually spits out the touchpad data. Installing the IDE, downloading the touchpad source code, and running it honestly doesn't require any programming experience, see the documentation here:
https://www.dropbox.com/s/ur152pz53va6g7m/GP-AN-180530%20Gen4%20Trackpad%20DevKit%20User%20Guide.pdf?dl=0. So that's one possibility anyway, you could order the dev kit and have your assistant help with assembling it (looks very minimal, likely just connecting the cables), then install the stuff and run the sample code to see how it responds. If it looks good, then I can order the dev kit myself and work on coding, etc.
Regarding the losing the ability to click at allThat was likely a state issue, meaning the app code has to keep track of things and due to erratic input or poor state management, the app likely got stuck in a state and was waiting for something to occur (or an amount of time to pass) before resetting things. It was likely some sort of race condition, clicking one of the physical buttons probably executed a different path which reset the state. That kind of stuff is very challenging to handle just right and properly recover - I'd say 50% of S+ development time (cumulatively) has been state and race condition management. This actually results in very little code, just spending hours working through conditions and possible events to add a few lines of code here and there - it's pretty tedious and I definitely did not spend a lot of time in this app working through those things.
Also note that the tap zones are only rendered when All Thumbs is active, to prevent using CPU cycles to draw the boxes and show the dot for where a finger is detected when it's in the background. So it just meant the app either wasn't active or it didn't
think it was active.
Edited by user Thursday, February 27, 2020 2:26:55 PM(UTC)
| Reason: Not specified