Display scratch answers in a faint font

[simonpoole1]

Hi - I came across your Shortyz fork and I'm interested in contributing some improvements. This is a simple one to get started.

This changes how the scratch note is displayed in the main grid. Instead of using a smaller font, it uses a thinner font and a lighter colour (setting the alpha so that it works on the highlighted background too).

Tested on day/night mode and looks okay to me. No need to test with error highlighting, because you don't get errors on scratch notes.

Hopefully you're okay with this change - I think it looks a bit better, plus my eyesight isn't what it used to be so the small font isn't ideal!

Could you also let me know your thoughts on the next change I would like to make, which is to add a pencil/pen toggle so that you can add scratch notes directly in the grid. For simplicity I would probably put the toggle in the menu initially (like Show Errors).

[yourealwaysbe]

Thanks for the work!

How does this handle the situation where the across and the down have different letters in the notes?

Writing directly into the notes sounds reasonable. I had been thinking lately that i would like to be able to promote/demote text between the notes and the main board, but wasn't sure best how to do it. This would suit my workflow better for cryptic crosswords -- write an answer tentatively so i can see it, then demote it to notes if i can't convince myself it matches the clue.

[simonpoole1]

Thanks for the work!

No probs :)

How does this handle the situation where the across and the down have different letters in the notes?

Hmm - hadn't thought of that. I'll test it and get back to you.

Writing directly into the notes sounds reasonable. I had been thinking lately that i would like to be able to promote/demote text between the notes and the main board, but wasn't sure best how to do it. This would suit my workflow better for cryptic crosswords -- write an answer tentatively so i can see it, then demote it to notes if i can't convince myself it matches the clue.

Makes sense. Would you be happy if I start with the way I proposed and then we can think about adding the demote behaviour later?

[simonpoole1]

Okay - here's an attempt to handle conflicting across/down letters in the same cell. If the letter is the same, it displays full-size, but if it conflicts then it displays similar to how it was before:

[matthewhague]

Thanks -- looks good. What do you think about making the notes font italic? It's a bit too close to the main font for my eyes.

[matthewhague]

Spotted a slightly tricky situation. In the screenshot below, it's not obvious how it should be read.

The words are "tricks" and "bent". The letters need switching here, but should be the other way if the words joined on their last letters. Is there a kind of smart placement that would work? Or maybe another kind of cue? One idea might be to keep the idea of small letters for notes, but make them only slightly smaller than the main font when there's room. The alignment would then still be the cue for how they should be read.

I think i would also make the font color in dark mode a smidge brighter.

[simonpoole1]

Yeah, good shout on all counts. I'd been wondering the same things. I can take a look at the weekend.

BTW - a few things irking me at the moment (in priority order) are (1) the keyboard keeps closing, (2) the backspace key on the keyboard doesn't work consistently, (3) I miss being able to use the Shift key to switch direction, and (4) I miss the directional keys on the Shortyz keyboard. I'll start taking at (1) and (2) next, but wanted to check if you've got any concerns. (I'll also start entering these things as issues in future to keep the conversation separate!)

On Wed, 6 Jan 2021 at 09:48, matthewhague notifications@github.com wrote:

Spotted a slightly tricky situation. In the screenshot below, it's not obvious how it should be read.

[image: Screenshot_20210106-093805_Forkyz] https://user-images.githubusercontent.com/22621435/103754126-d72b5f80-5003-11eb-93c5-39bc16a276c6.png

The words are "tricks" and "bent". The letters need switching here, but should be the other way if the words joined on their last letters. Is there a kind of smart placement that would work? Or maybe another kind of cue? One idea might be to keep the idea of small letters for notes, but make them only slightly smaller than the main font when there's room. The alignment would then still be the cue for how they should be read.

I think i would also make the font color in dark mode a smidge brighter.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/yourealwaysbe/forkyz/pull/12#issuecomment-755197586, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZLICEU3T7GJA34LFM2HBLSYQWV3ANCNFSM4VSDUT6Q .

[matthewhague]

BTW - a few things irking me at the moment (in priority order) are (1) the keyboard keeps closing, (2) the backspace key on the keyboard doesn't work consistently, (3) I miss being able to use the Shift key to switch direction, and (4) I miss the directional keys on the Shortyz keyboard. I'll start taking at (1) and (2) next, but wanted to check if you've got any concerns. (I'll also start entering these things as issues in future to keep the conversation separate!)

1. This is deliberate -- i prefer the keyboard out of the way. Adding a keyboard show/hide mode option would be ok -- i guess the KeyboardManager hideKeyboard method could be a no-op if the option is set to always show (there used to be an option for this, and i added a KeyboardManager class to try and manage the complexity, but then removed the option along with the non-native keyboard (see below)).
2. Hah, yes, never noticed that. The code of the app is generally a mess -- perhaps this is a good excuse to move all keyboard behaviour to one place? (edit: actually the Playboard delete is a different situation to the BoardEditText delete, so trying to merge behaviour would probably be a disaster. I guess just the BoardEditText delete needs adjusting -- or both, i've never been convinced that the delete behaviour is the right one.)
3. I never noticed that, nor deliberately removed it, so don't mind it going back.
4. I deleted the Shortyz keyboard to make maintenance easier. There's some resize behaviour associated to the show/hide of the keyboard that i found fiddly enough to make acceptable for one keyboard mode, i decided i couldn't be bothered to make it work for a keyboard i never used. If you add it back, it would be worth looking for a way to do it without having to add it as a widget to every screen of the app. (edit: the arrow key code is still there and works if your keyboard has arrows. The best solution might be to install a keyboard (e.g. Hacker's Keyboard) with arrow keys rather than implementing a new one in Forkyz. A "never hide keyboard" option would be needed to make it useful though -- else pressing up hides the keyboard as well as changing clues, which is annoying.)

[matthewhague]

(2) the backspace key on the keyboard doesn't work consistently

Fixed in bfd563c.

[matthewhague]

(1) the keyboard keeps closing

Partial fix in b520b02 -- option added to stop hiding of keyboard.

This does not force the keyboard to be shown at all time. I ran into a common problem on stack overflow when trying to do this -- calling showSoftInput during onResume does not show the keyboard. The common hack is to delay the call to showSoftInput by 200ms, but i don't like this solution because it's a hack. Another suggestion was to use a ViewTreeObserver to get a callback when the view has finished being laid out. However, this still did not work as there seems to be another layout after the first (perhaps caused by the keyboard showing) which hides the keyboard again. You can force it to show the keyboard everytime a layout is completed, but then you can't hide the keyboard ever (and it might be obscuring parts of the screen).

[simonpoole1]

I've fixed the across/down alignment issue and it looks a lot better now, and made the text slightly less faint in night more.

Regarding making the notes more distinguisable from real answers: I had a play with italics but I've landed on making the letters slightly bolder and slightly smaller instead. I thought the italics looked a bit harsh/ugly in that all-caps sans font. What do you think of this?

[yourealwaysbe]

Looks good at a glance -- definite improvement over the old :)

I'll play with it a bit to see if any tweaks come to mind.

[yourealwaysbe]

Looks great -- merging now. Thanks!

[yourealwaysbe]

(4) I miss the directional keys on the Shortyz keyboard.

I looked into input methods and the KeyboardView was a bit clunky to start with, but now Android has deprecated it, with the recommended replacement being to copy-paste the old KeyboardView.java file (~1500 lines) into your own project. This makes me even less keen to bring it back.

As an alternative, what do you think of a Vi-style keyboard? Default is input mode, but if you press enter it goes to "normal" mode. Then h, j, k, and l can work as arrow keys, then the other keys can be used for additional features as desired. E.g. "s" to switch the current board answer to scratch or vice-versa.

[simonpoole1]

(4) I miss the directional keys on the Shortyz keyboard.

As an alternative, what do you think of a Vi-style keyboard? Default is input mode, but if you press enter it goes to "normal" mode. Then h, j, k, and l can work as arrow keys, then the other keys can be used for additional features as desired. E.g. "s" to switch the current board answer to scratch or vice-versa.

I'm actually thinking it might be easiest to add some on-screen nav buttons pinned to the bottom of the view. I'll have a play with that and see if I can get something reasonable working.

[yourealwaysbe]

I'm actually thinking it might be easiest to add some on-screen nav buttons pinned to the bottom of the view. I'll have a play with that and see if I can get something reasonable working.

Worth a try -- i'm not sure if it will be hidden by the keyboard though if the screen isn't long enough.