what's allowed and what's not, I have a pretty good idea what's going
on behind the scenes. They've definitely put some brute force into
it, that's for certain.
Dean
On Jun 2, 4:09 pm, "I...@wesleyacoustics.com"
<I...@wesleyacoustics.com> wrote:
> Have you looked at the Jump terminal services app? They have arrow
> (but not meta) keys working in their app and seemed to have similar
> problems to start out. Not sure if they'd be willing to share their
> approach if they had something figured out or not.
>
> On Apr 7, 12:55 pm, Dean <canada...@gmail.com> wrote:
>
>
>
> > Doug,
>
> > This is exactly the frustration I'm dealing with. The UI components
> > themselves receive the arrow keys and other such commands without an
> > issue. The problem is that in the simulator, they do make their way
> > back as key events to my code. On the real device, they're never sent
> > and I have no way of telling if they were. I think the best solution
> > for the moment may be to create an efficient keyboard accessory as
> > requested in another thread. Long term, I will file a support issue
> > since I figure at least receiving arrow key events will be a common
> > interest among a lot of apps (not just terminals but games too!) and
> > if I can capture the meta keys as well, that's just gravy!
>
> > Dean
>
> > On Apr 7, 7:45 am, Doug DeJulio <dfjdeju...@gmail.com> wrote:
>
> > > I can confirm that Apple's own apps are responding to the control key
> > > combinations. Here's the simplest test to prove it. Bring up the
> > > "Notes" app and place the cursor in the middle of a note. If you
> > > press control-f, the cursor will move forward, and if you press
> > > control-b, the cursor will move backwards. That is, a subset of the
> > > Emacs editing functions works fine. Also, control up-arrow jumps to
> > > the top of the document, and control down-arrow jumps to the bottom,
> > > and tab inserts a tab.
>
> > > Escape does not do anything, but this doesn't surprise me as a close-
> > > up image of the keyboard dock shows that it does not *have* an escape
> > > key. But it has control and arrow keys, and a tab key.
>
> > > The best image of the keyboard dock I've found, the only one that let
> > > me read all the key caps clearly, can be found by going to the Apple
> > > store and searching for the keyboard dock, clicking on the thumbnail
> > > for the image of the keyboard alone, and then clicking with the
> > > magnifying lens cursor. You then get an image big enough to read, but
> > > you have to pan it around -- except you can then open that image in
> > > another window. I'd post the URL here, but it's handled by Akamai, so
> > > sharing my own URL with geographically distant people would probably
> > > be non-optimal.
>
> > > I've been studying it so as to set my expectations reasonably. I am
> > > expecting that eventually all the functions shown on that keyboard
> > > will be fully supported, but I'm not holding out hope for keys that
> > > are conspicuously absent from the keyboard dock, most notably the
> > > "escape" key (I can re-adapt to control-leftbracket, I've had to on
> > > terminals in the past) and the "fn" key.
>
> > > Some other tests: command-up-arrow also jumps to the top of the
> > > document, and command-down-arrow also jumps to the bottom, but command-
> > > f and command-b do *not* move the cursor forwards and backwards. So
> > > the command key is getting through as well, and is not treated
> > > identically to the control key. The option key behaves as MacOS has
> > > trained me to expect. For example, option-o produces a "ø" character,
> > > option-8 produces a "•" character, option-shift-8 produces a "°"
> > > character, and so on. Even option-n followed by an n produces a "ñ",
> > > by first producing a hovering tilde in a strangely colored box, and
> > > then replacing that glyph with ñ when the n key is hit the second
> > > time.
>
> > > (Also, the bright/dim keys work, the volume keys, including mute
> > > toggle, work, and the media playback keys work. The "eject" key is
> > > interesting; it toggles the on-screen keyboard, bringing it up or
> > > dismissing it. The exposé and dashboard keys do not do anything at
> > > all.)
>
> > > On Apr 4, 6:48 pm, Dean <canada...@gmail.com> wrote:
>
> > > > For those attempting to use the Apple bluetooth keyboard to it's full
> > > > capacity (with arrow keys and all) you'll discover rather quickly that
> > > > iSSH does not recognize these keys. This does not match the simulator
> > > > behavior with a "simulated hardware keyboard." Arrow keys, ESC,
> > > > function keys, etc. all seem to work fine typing using a regular
> > > > keyboard into the simulator. However, from a real keyboard to a real
> > > > device, key events don't seem to be generated (at all) as they do in
> > > > the simulator.
>
> > > > So, after a some research I'm beginning to think there's some
> > > > disconnect, either between the iPhone OS or the simulator's
> > > > implementation that leads me to believe that the keys are not
> > > > supported at all or simply not yet.
>
> > > > I'm going to keep at it but at this point I'm not sure what can be
> > > > done. I'll keep everyone posted so watch this space. I'll be posting
> > > > something on the website too so I can let people know of this issue.- Hide quoted text -
>
> - Show quoted text -
--
You received this message because you are subscribed to the Google Groups "iSSH/iX11" group.
To post to this group, send email to issh@googlegroups.com.
To unsubscribe from this group, send email to issh+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/issh?hl=en.
Comments
0 comments to "Re: Bluetooth Keyboard Support"
Post a Comment