OpenMpt accessibility discussion

[GoemonIshikawa]

Okay, I have logged the control state issue, though in the end I think it's best to keep it open at least until the next release in the event of any regressions.

[Saga Musix]

Okay, I have logged the control state issue, though in the end I think it's best to keep it open at least until the next release in the event of any regressions.

That's generally not how we work - if an issue is later found, the ticket can always be reopened, or be amended with another ticket. As mentioned before it's also not helpful to conflate multiple separate issues into one, such as the "steps to reproduce" in this particular example. Were these issues fixed in two different OpenMPT versions, it would be impossible to properly tell them apart on the issue tracker.

Generally we also don't retroactively create tickets for something that has already been fixed: The issue tracker is not a complete list of bugs or changes in the software. All user-facing changes are documented in History.txt instead.

[GoemonIshikawa]

Okay, I have logged the control state issue, though in the end I think it's best to keep it open at least until the next release in the event of any regressions.

That's generally not how we work - if an issue is later found, the ticket can always be reopened, or be amended with another ticket. As mentioned before it's also not helpful to conflate multiple separate issues into one, such as the "steps to reproduce" in this particular example. Were these issues fixed in two different OpenMPT versions, it would be impossible to properly tell them apart on the issue tracker.

Generally we also don't retroactively create tickets for something that has already been fixed: The issue tracker is not a complete list of bugs or changes in the software. All user-facing changes are documented in History.txt instead.

@Saga Musix Oh I understand. Yes it's just another thing that happeneds when I'm on GitHub, most to all accessibility work usually just goes in the description field and anything worked on is usually kept track and closed afterwards, but in next event I can delegate minor issues or things that require your understanding to forums and the major issues to bug tracker.

I honestly  did it like that as I thought it'd be much more easier to read for anyone looking at it as while they might look like separate issues they're really two parts of the one problem, though to be honest I should've kept it to description field as in GitHub as now that I'm seeing it, it probably isn't easy to keep track of like I'd thought.
Thanks for the heads up on the matter by the way.

[GoemonIshikawa]

Hello!
@Saga Musix I got the latest version of OpenMPT as of 19 July, but I'm afraid that the keyboard issue still persists, as the information given in the keyboard creator isn't focusing when in list controls. I made the choice to use the updater to update to the latest preview, but found another minor keyboard bug within the updater. It looks as if even though the install update keyboard command *Alt+I* is given to install the update, nothing actually happeneds when pushing the command. Let me know if you need me to be clearer on anything at all and I will do my best!

[Saga Musix]

but I'm afraid that the keyboard issue still persists, as the information given in the keyboard creator isn't focusing when in list controls

You are right, but upon closer inspection, list views behave the same way no matter where they are used in OpenMPT. This appears to be a quirk of the list view control. Since OpenMPT is built entirely on top of standard GUI controls provided by Windows, there isn't much we can do there, and you will probably find the same issue in any other software using the same list component.

It looks as if even though the install update keyboard command *Alt+I* is given to install the update, nothing actually happeneds when pushing the command.

Alt+I is the default keyboard shortcut for switching to the instrument library. User shortcuts take precedence over accelerator keys. If you want to be sure that custom keyboard shortcuts are never in conflict with accelerator keys, you would have to find all shortcuts assigned to any of Alt+A...Alt+Z and unassign them or assign them to a different key combination.