More fun scripting with Swift and Xcode: huge popups, and strings too smart

How many items can you squeeze into a popup menu? I can manage 144 now, and amazingly it remains eminently navigable, at least from a Magic Trackpad.

Generating the array of strings to form each of the two popup menus was straightforward: I piped the output of the command to list all the supported encodings from iconv into a text file:
iconv -l > encodinglist.text

Each line in that file is a single encoding, with the synonyms given in that line. So, for example, the first line reads
ANSI_X3.4-1968 ANSI_X3.4-1986 ASCII CP367 IBM367 ISO-IR-6 ISO646-US ISO_646.IRV:1991 US US-ASCII CSASCII

All those encoding names, recognised by iconv, are synonyms for what most of us would just call ASCII. So I worked through that listing, reducing each line down to just one of the synonyms for the popup menu entries. In BBEdit, sorted those alphabetically, then replaced all \n newline characters with ", ", put an opening [" and a closing "], and it was ready to drop straight into my source.

rosetta4

Yes, the popups are monsters, but using them seems fine. They are certainly superior to nested menus, or scrolling lists. I will need to list synonyms in the Help Book, but that shouldn’t be particularly onerous either, using the listing that I now have.

rosetta5

Now the popups work, the command is generated correctly, its errors handled acceptably, and all should be ready for a beta release. But there’s one rather frustrating problem getting in the way.

The two scrolling text views take attributed text, in NSAttributedString form. In order to convert from the raw data read from the input file, and to write to the output file, this has to treated as an encoded NSString. Unfortunately, that means that it is parsed and checked against that encoding, and won’t, for example, accept UTF-16 if the encoding is UTF-8. So the only means that I can (currently) see of getting text into or from those text views has to assume a text encoding which could well be incompatible with the actual raw data.

One way of working around this is to store the raw input and converted data, to write the raw converted data rather than that from the re-encoded content of the output view, and to convert that to the most appropriate representable form for display. I need to spend a little time experimenting with this in order to get it right, so that the user sees the most faithful representation possible, and the app doesn’t barf or crash.

That is the sort of task which would have been nice to perform in a Swift playground, but because it is heavily dependent on views and view-related functions, that looks impossible.

I’ll be back once I have worked out a solution.