OK, I'm revisiting my post from last week. I was certain that I could reduce the time it took to enter data with some simple modifications. The results are at the end. The main change was the removal of the suggestion frame from the right and its replacement with a suggestion label positioned under the box that's currently in focus. Take a look at the previous version to see the difference. Another change was that previously pressing enter while in an entry box had no effect. Now it selects the first suggestion and moves focus to the next box down.
These changes reduce the number of keypresses and the amount of scanning that your eyes need to do of the on screen data. I was also feeling a little nostalgic, so I've chosen some 4-bit colours for different elements. :-)
|Data entry with suggestions|
The window is broken into two different frames, divided at the blue line, one on the left for the image to process, and one on the right for the entry boxes and the status label. The second frame in arranged into 11 rows, divided at the red lines, with the grid manager.
|Arrangement of input window|
The hard bit however was getting the suggestion label to be placed under the entry box. First of all, a few things need to be discussed in the image below.
The frame is divided into 3 columns indicated by the blue lines. This allows small coloured indicators besides the entry box to indicate which one has focus. This is done because ttk entry boxes don't allow the background colour to be changed. The small coloured regions are fixed size and the entry box is allowed to resize to fill the rest of the space.
The next step isn't as simple as placing a label under the input box. First a frame needs to be inserted with the place manager that's underneath the entry row and is the same width. This frame is outlined in yellow.
This then has the suggestion label inserted in the frame. The label stops at the green line.
I hear you say that's weird, why not just add the label under the entry box, why use a frame? It's because of how tkinter handles long lines in labels. I construct a string of text to add to the label that contains carriage return characters (\n). This usually works for small lines, but for long lines, the string is cropped to make it fit the label. It doesn't realise that the carriage return characters start a new line. Fox example, the string
really long text part one \n really long text part two \n really long text part three
would display correctly on three lines if the label was wide enough. However if the label was only wide enough to display 4 characters, it would display "real" once and then crop the rest of the text before it gets to the carriage return characters. What you probably expected to see was:
The way to get around this is to create a frame of the correct width and then place a label in it that has no set width. The label will then resize to a width to fit all the text, while the frame acts to crop the text limiting what's shown.
So did the entry speed increase? Yes it did. In my last post I noted that typing the text with no assistance took about 90s per image. My first attempt took 1:25:41 for 76 images or 67s per image. This new arrangement allowed for a time of 1:07:26 for 76 images or 53s per image. I'm pretty happy with that. That's a 40% decrease in the input time from unaided and a 20% decrease from the initial attempt. Although I'm likely to get faster the more I type the data, the tests were a week apart so I think this effect is minimal.
|Get the code|