Closed thanneken closed 6 years ago
Testing on Ubuntu with a 4K display revealed another consideration. The available hemisphere captures were all listed, but out of order. The options started with "B" and the "A" positions were between "F" and "G". Either alphabetical or date sort should put A first.
I will test and replicate this issue, I had sensed this before but couldn't articulate into an issue.
Sorting should not be an issue, I will see if I can run any sorting on the Path arrays.
I will do this after initiating the array just after declaration so the code always interacts with a sorted array.
Dialog sequence is now as expected.
Today I noticed that with Xs it created the jp2 files in the same run as creating the jpeg files, while with Ac it created all the jpeg and then went back to do the jp2. The behavior observed in Xs seems preferable because the core processing is not duplicated. This would be noticeable if someone wanted all the positions created for static raking (plausible).
Two minor UI observations:
1) At first run it seemed like G15 was checked by default. I could be mistaken. 2) Clicking on a raking image name to preview it would still be welcome.
It seems this window is in order. You can hover over a name to get a tooltip of the full file path, I did not connect it with a click event. I did not experience G15 selected by default. I will create a new issue for the previous comment.
Horizontal scrolling through the full file path is not very neat. I think there may be an additional problem. On Ac I thought I selected A03, A13, G05, G13 and got no static raking output or prompt for kdu_compress. Later I was on Xs and mistakenly selected only A03 and A13, but it successfully asked for kdu_compress and generated static raking for those two and diffuse.