You are correct, the driving controls in AVP don’t use dwell, that is the wrong (and dangerous) approach. They use something more akin to hover activation.
It’s the hardware I designed coupling the power wheelchair to the AVP, and I’ve driven it myself.
Yes, daily, as a virtual screen for my Macbook using a BLE mouse and keyboard paired to the Macbook not the AVP. Then I supplement the Mac with the occasional AVP side app using fingers and eye gaze control.
If only the AVP ran MacOS natively on the M2. Somewhat ironic that I have to park an M1 Macbook on a table next to my AVP, screen open so I can unlock it (requirement for the screen pairing).
I’m considering putting my Mac Studio into ‘never screen lock’ and then using a long range Logitech dongle for the wireless keyboard and mouse so I can use my AVP without an opened Macbook by my side all the time.
A big bonus for me was VisionOS 2 added lower latency screen mirroring (and I think foviated rendering of the mirrored screen). Prior to that I had to use a developer strap with a second usb cable to the Macbook to get no noticeable latency on the screen and cursor.
Strongly disagree. As a dev who’s been in the business since the days of the first gui apps and OSes, UI can be very straightforward, but we have designed modern systems such that they are immensely complex.
Styles and inheritance and asynchronicity have turned what could be a simple approach into an inscrutable problem.
Ui can only be as straightforward as a user wants it to be - if all user wants is pressing couple buttons to open couple windows - then yes, it is straightforward.
Asynchronicity is not a problem it is one of the many solutions to help alleviate the problem.
Having submitted a number of “product breaking bug reports” through official channels while using a paid support incident, can confirm Kafkaesque and a multi year support process.
Oh, I can get a person to “respond” to a problem with a paid support incident. But the person responding is clearly hired only based on their ability to respond to an English email, once a week, with either, “thank you, I will forward that to our engineering team” or “thank you for your patience, our engineers are still looking into that issue.”
Severity, impact, paid support, none of that matters. Heck, it’s impossible to tell if it’s an actual person or just a sophisticated shell script.
Spoken like someone who hasn’t put a match to gasoline.
Having recently used gas to help start a wood slashings pile on fire, gasoline is very explosive and dangerous.
Diesel will burn in place when lit. Gasoline vaporizes when let out if its container in ‘room temperature’ conditions and creates a vapor fireball when it finds a nearby ignition source.
Never use gasoline as an ‘accelerant’ to start something else on fire —- it’s way too dangerous.
Probably a much simpler answer. The programmers who work on a washing machine are probably inexperienced low wage disempowered help. And there’s an innocent rx/tx loop for a home grown notification system and noone on the team knows better or knows how to use a packet sniffer or perf analyzer.
Never attribute to malfeasance what incompetence can explain.
Put a packet sniffer on it. Bet it doesn’t use https, that costs extra for microcontrollers. Dollars to doughnuts it’s a teenager on a road trip.
Are we there yet? Are we there yet? Are we there yet?
This was my experience too. While it takes a good long while to get resolved, because my mistakes were accidental and I talked it through and followed the process, I was dealt with politely and given grace.
It’s the hardware I designed coupling the power wheelchair to the AVP, and I’ve driven it myself.