On 1 March 2011 20:08, Jorge Silva<jsilva@xxxxxxx> wrote:
Actually, I've been thinking about exposing all switch states whenever
anything changes and let applications process the difference. Maybe I'll add
it as a future for subsequent releases.
You'd have to change the bluetooth protocol as well as the switch
events broadcast, but it might have advantages...
I just added the Android IDs to the table. Extra switch 2 won't work but
extra shield 1 should. Could you confirm? If it doesn't work let me know and
we'll set up a time to go through the firmware upgrade for the Proto I.
Confirmed not working, am afraid :-(. I had a catch-all case "unknown
switch extra" which was printing out the release-events, and it
doesn't produce anything if I connect a single switch directly into
the jack socket. Although, just to check: the switches are 3.5mm mono
jack plugs, there's no possibility the socket is something else (e.g.
using a stereo socket in some incompatible way), is there?
We may be able to fix the pop-ups with a custom theme and students from UBC
are working on the menu. Hopefully we can come up with a good solution.
Sounds like a good plan, indeed. To test, can you still send
up/down/etc. keypresses even with the window invisible? Not a whole
lot of use I admit but if so there may be workarounds...
Re: using single switch with Dasher, currently the switch is an overlay called
by the IME, so I need to move the code to the SEP so it can be exposed to
otherapplications/IMEs. This should be part of the wider discussion
regarding the future of the SEP
Not sure what you mean here - do you mean the _navigation keyboard_
"is an overlay called by the IME"? If so...I'd think that was as it
should be...but we can talk about this wrt the SEP interface, indeed!
Cheers, Alan
