Arrgghhh… now I can’t seem to reproduce this anymore. Grr. I’ll try to pay more attention so that if it happens again, I can try to figure out what triggered it.
1 Like
Could it be that the “booted emulator” was still selected from when you ran the project in a previous Fire build?
The way not works now, Fire’s upper level doesn’t see the emulator-<port>devices at all anymore. it sees real devices, andemulator-`, which are derived from the configured emulators. the port-based names are mapped purely internally in the low-level Android device management, now.
It’s entirely possible. I’ll let you know if I run into this again.
1 Like
Yeah, the problem is reliably finding it :(. My emulator shows as this, which is hardly detectable or gonna be the same everywhere. no BundleIdentifier, no Bundle URL, and a display name thats not gonna be reliable 
<((null) - 21748)>: , qemu-system-i386,
When I log the executableURL property of the NSRunningApplication for the emulator, I get:
file:///Users/[redacted]/Library/Android/sdk/emulator/qemu/darwin-x86_64/qemu-system-i386
The executable being inside ~/Library/Android/sdk/emulator should be a pretty good giveaway, I think.
Good call, yeah, I’ll use that.
By the way, disassembling the app, it appears that the main text widget is FCECanvasCodeSnippet—that’s where I’d add NSTextInputClient support. Just conform to the protocol, implement its methods, and then override as many of the IBActions in NSResponder.h as you can. Your users will love you, and you’ll probably be able to toss out a bunch of custom code that does stuff the framework already takes care of. And then, Fire will just work with:
-
All standard text shortcuts built into the OS
-
All standard text shortcuts that get added in future versions of the OS
-
All custom shortcuts that your users have set up
Plus, you’ll probably be able to delete a lot of custom code that does stuff already handled by the framework. It’s a major win for usability.
Yeah, unfortunately that’s not going to be as easy as that, as that would essentially be a full rewrite of the editor control.
As someone who’s implemented NSTextInputClient for a hex editor view, it’s not as hard as you think it is 
Obviously I can’t see your Objective-C code, but in the general case you just need to get rid of the stuff that watches for key input and rewrite that to use insertText:replacementRange: as the entry point, and a lot of the rest can be repurposed.
In addition to the benefits I listed above, NSTextInputClient support also makes you compatible with input methods other than the keyboard, which is important for accessibility.
Yes, I’m sold on the idea, I just dnt have the month to spare to completely reinvent the code editor from scratch, right now
Bringing the emu to front is done, for tomorrows build. Only will hoopoe if there’s only a single emu running.