[swift-evolution] [Meta] Let's talk TouchBar + Unicode
Haravikk
swift-evolution at haravikk.me
Sat Oct 29 05:10:35 CDT 2016
Eh, I'm all for better emoji support but I think this needs to come in at the OS level.
Part of the problem for emoji is that the macOS special characters menu is so awkward to use; coincidentally I actually posted an enhancement request to the Apple bug reporter only yesterday asking for a more Spotlight-search like special characters selector. i.e- rather than the the awkward, tiny and hard to dismiss window something with immediate searching by relevant tags, either narrowing down for easy selection, or hitting enter for the top result.
In short; I don't think it's a Swift or even Xcode specific issue, and definitely shouldn't be part of auto-complete IMO. The real problem is that the macOS special characters selector is terrible, and has changed very little since OS X first appeared, except to be slightly rebranded for emojis (despite being no easier to use). Most apps that provide their own picker are vastly superior.
> On 29 Oct 2016, at 01:34, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
>
> Given that Swift supports unicode, and it looks like this TouchBar will make typing relevant characters/symbols much more accessible/discoverable, I think we should move forward with the assumption that we will be able to type (somehow) whatever symbol we feel best represents something, and we should start looking for opportunities to use this where it makes sense.
>
>
> The big issue is how to provide similar support for pre-touchbar devices (and non-Apple devices), and there are lots of options (of which I will list just a few below):
>
> • Have emojis and symbols in the autocomplete list when appropriate by typing human readable names (i.e. ‘Dog Face’ instead of U+1F436, or ‘union’ for ∪). Optionally, we could have an easy symbol (e.g. $ or ^) which hints to the autocomplete that we might want a symbol (similar to how typing @ in Facebook brings up an autocomplete list of friends). Thus typing ‘^u’ would bring up '∪' near the top of the list (and you could continue typing ‘^union’ if needed to disambiguate)
>
> • Allow autocomplete when using the short code (e.g. :dog: for 🐶)
>
> • Have a bar along the bottom of the screen (kind of like the one which shows up when a keyboard is docked with an iPad) which maps to the function keys, and has similar options to what the TouchBar would have.
>
> • For those using just a text editor, utilities like TextExpander (or the built in text expanding capabilities of OS X & other platforms). Pretty much every platform has a built in way to type unicode/emoji. It may not be the easiest, but hey, that is true of many platforms in general. There typically exist utilities to make it easier.
>
> .
>
> My main point, is that we should proceed as if everything we want to do in terms of input is possible, and trust that the Xcode team (and other IDE developers) will do what is required to make it work (or will speak up in particular cases to tell us we are headed in the wrong direction)… as opposed to assuming that things are impossible and not pushing the limits at all.
>
> Note: I am not saying we should use these things frivolously… just that we shouldn’t be afraid to use them when they make a lot of sense (We have previously rejected several proposals because they are hard to type on one kind of keyboard or another).
>
> Thanks,
> Jon
>
> PS. I am also ok having some overlap (e.g. both the union operator and ‘formUnion’, where one maps to the other) while technology is disseminating. They can always go through a depreciation cycle later if we decide to consolidate. I just don’t think we should wait, because then we will never start...
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list