Open srigi opened 9 years ago
It is also possible to allow for configuration (but perhaps this would be over-engineering).
An additional line above the keyboard seem better than a whole new keyboard. See http://www.textasticapp.com/iphone.html for an example of how you can compress a lot of special characters into that one line.
Looking for an accessory toolbar pod to borrow, being new to iOS, I found @tnantoka Editha editor on github:
https://raw.githubusercontent.com/tnantoka/edhita/master/screenshot.png
I will push to a branch/clone a reimpl of the repl controller with the EDHInputAccessoryView. I also had to move the TextInputView off the accessory bar and onto the last cell in the table, more like a repl console in any case. I did not keep the Eval button, but can put that back if needed.
Interesting. The things to perhaps look out for are when you swipe down to eliminate the keyboard. I wonder if that leads to a reasonable experience if the TextInputView is not attached to it. It is worth trying, though.
Another thing to try is having the TextInputView grow if you enter multi-line forms, like it currently does.
I'd try to retain the Eval button (it is useful if you are editing something in the middle of a form and want to evaluate instead of relying on enter to evaluate when at the very end of a form.)
@asheldo Also, perhaps what is currently the TextInputView can be kept but with the accessory view holding 2 subviews, one for the TextInputView and one for the extended row of keys.
Does the extra row of keys make sounds that sound anything like the real keyboard? That'd be really cool if that were implemented.
Re-hydrating my Developer account, so I can really test on the iPad. I initially failed with combining the existing bar and the buttons bar as subviews, but I could try that again at some point. I figured by now I would have gotten around to figuring out a Textastic-style composite buttons bar, but no. I've used Textastic on the iPad quite a bit and thought composite buttons were cool, but after a couple of spins with this sliding toolbar, Edhita-style, I think I find it a bit easier/more fluid somehow. Thanks!
Yeah, that top one looks strange, with the input text field floating way up there. The bottom one looks better.
I wonder what this looks like on the iPhone.
Thanks, @mfikes! I'll try some different things in https://github.com/asheldo/replete.git -- master currently looks like above.
@asheldo This custom keyboard looks awesome, IMHO, but it is plagued by a subpar implementation (great "look" but bad "feel"):
Hey @asheldo, when you get your account re-hydrated, take a look at iOS 9. Some stuff has changed with the keyboard and I'm wondering if that might provide a cleaner solution to all of this. The beta is public so there are probably pictures out there showing what I'm talking about.
I pulled in the EDH bar source, tried adding the eval button and click sounds, and correct text box resizing. I haven't tried 9.0 yet, but I did start playing with iPhone in simulator. I'll try a different quick bar at somepoint, as well as moving the text input down to the bar. Thanks again!
That's cool. I tried building the Objective-C branch of that project but it fails with missing headers.
I wonder if we have any flexibility to make it look like the picture I had pasted earlier https://github.com/mfikes/replete/issues/62#issuecomment-127975753
I suspect that we can probably get the text input box margins / etc to look right, with the Eval button on the right (all mimicking the Send button in the messages app). But, I suspect that if we make the additional row of keys look too much like the stock keyboard keys then it would feel odd (because I'm guessing when you tap one of those keys, it probably doesn't do that thing where it reveals what you are pressing.)
With iOS 9, I think some of those buttons near the left of that row of buttons are already there. (And I'm wondering if iOS 9 lets developers add their own buttons, and if so, are they really for things like undo/redo, cursor movement, etc., and not meant for character input.)
Sorry, did you pod install?
Ahh. No... will try again. :)
Keyboard layout should be optimized for Clojure. That means on 1st keyboard variant there should be chars essential to Clojure programing:
Maybe this list needs be discussed more.