gui: Slot selection
Why?
Currently, edition is basic and is made box by box, navigating with arrow keys or with the mouse.
There is no live indication of the possible words of the slot being edited, since there is no notion of slot in the GUI, just boxes.
One has too look in the dictionary if word is present. One has to prepare the grid then run solver to see if there is solutions and if there is none, rework the manually entered grid based on problematic boxes highlighted in red (based on information returned by the solver, and all solvers do not provide valuable information).
The feedback loop is slow, it is very manual. Which is OK for people not wanting to rely too much on the machine. But it might be better for the casual user.
The first step to provide useful information about a slot in a GUI is to actually have a notion of slot in the GUI.
What?
Introduce the notion of slot in the GUI. Basically:
- When user clicks on a box: Highlight the horizontal slot the box is part of
- When user clicks again on the box: Highlight the vertical slot the box is part of
- (Maybe) When entering letter, automatically go to next letter of the slot. I don't know why but I don't like it too much. I find it a bit annoying if you mistype or if you want to check several letters for a single box.
Here are some examples from other editors:
- GNOME Crosswords Editor
Default orientation is the last used orientation, or horizontal on first selection. Slot is highlighted in yellow, box in blue. Does not auto-advance to next box while typing. Slots are automatically numbered.
- qxw
Default orientation is the last used orientation, or horizontal on first selection. No specific highlight of the slot. Orientation is indicated with an arrow in the box background. Auto-advances to next box while typing. Slots are automatically numbered.
How?
- I guess there's the need for a type representing the boundaries of a slot, like
SlotDefinition
incroiseur-solver-ginsberg
. Maybe be that should be common, a domain object. - Based on shaded boxes, GUI has to live-calculate the slots present in the grid view. Like
GridDataBuilder
incroiseur-solver-ginsberg
, but dynamic (and hopefully less horrible). Again, probably some things to be shared between the two. - The current slot should be exposed as a property of the view model. This will allow later to present the possible words for the selected slot.