Ignore multiline pasteboard text at launch

[willhains]

The new feature added in #41 to automatically detect text on the pasteboard, and offer to use it as a search, should ignore pasteboard text that contains newline characters, as it is unlikely to be useful as a word search.

[chockenberry]

I did this in my latest pull request (#45).

[willhains]

I have another idea for a useful way to handle the pasteboard. I'm attempting this locally now...

1. Read the pasteboard at launch, and monitor changes to it.
2. Split the pasteboard string into words by whitespace (including newlines).
3. Filter for simple words ("of", "and", "to", etc.).
4. Filter for tokens that are unlikely to be words, or likely to be passwords, e.g. containing a symbol or digit character.
5. Display words as a list, underneath the "Type a Word" text entry field.

Motivations / expected benefits:

• No extra taps or interruptions for the user upon launch. They can tap a word from the pasteboard, or just start typing as before.
• When used in iPad multitasking (SlideOver, split screen), the user can simply select and copy text in the other window, and instantly see Kotoba update to show the copied words. One tap to see the definition.
• I'm even considering moving the history into this list, as a separate section, making this effectively a one-screen app. Even fewer taps to get to what you want. (Possible privacy issue?)

[willhains]

Reminder to self: Make sure the filtering of the token list doesn't mess up non-English/non-Latin-based languages.

Also, remember to support tokenise languages that don't use whitespace as a word separator (close to my heart: Japanese). Some info on how to do that here.

[chockenberry]

I like this idea: anything that gets rid of an alert is a good thing. Also solves the issue of multiple prompts for same clipboard contents.

You’ll need to do it at app activation, not launch, though. Kotoba can hang around in memory for quite awhile (small footprint).

I think putting history on the first screen will just add noise. Love the simplicity of *Type a Word”.

[chockenberry]

Let me know when you're done with this work - I have some ideas on how to improve it.

Basically, I don't think the entire view should be a table view. Putting "Type a Word" into the header lets it scroll off screen and forces a weird position at the top of the view (the first a bad experience, the second is bad visually.)

Instead, I see the parsed words being put into a scrolling container (table view) in the view with other non-scrolling elements. If there is data on the clipboard, you can adjust the layout constraints at runtime to provide a maximal amount of area for the detected words. It's the best of both worlds and easy to do if you know how. I do :-)

[chockenberry]

Overall, this is a very elegant way to handle the data detection. Good work!

[willhains]

Yes, I realised the problems with using TVC pretty soon after I got it working. I’ll change it to an embedded view, and keep the “Type a Word” visible always. That should always be the primary way to use the app, and should therefore have visual priority as well.

[chockenberry]

Here you go: https://github.com/willhains/Kotoba/pull/47

[willhains]

Outstanding:

• [x] ignore probable passwords
• [x] ignore trivial words ("of", "and", etc.)