This string is extremely likely to be mistranslated without the
proper context. Actually, it's probably impossible to translate
this string in a good way to some languages, but I'm not sure how
to solve that. Let's at least add an i18 comment for now.
Yes, that's right! It's time to add even more NKit warnings,
because users still don't understand what NKit is or how it works!
More specifically, some users seem to be under the impression that
converting an NKit file to for instance RVZ using Dolphin's convert
feature will result in a normal RVZ file, when it in fact results in
an NKit RVZ file (since NKit is not a container format in the sense
that GCZ/WIA/RVZ/WBFS/CISO is, but rather a kind of trimmed ISO).
I can hardly blame users for not knowing this, because it's not
intuitive unless you know the technical details of how NKit works.
Previously, the file dialog window was ambiguous between saving or loading a .dtm. This commit simply gives a bit more context to differentiate the two windows.
If this commit is not applied, then the previous commit will cause hotkeys to be saved if there is a syntax error when hitting "OK" and the user presses the X to close the window.
This commit only applies changes to hotkey config if no syntax error occurs.
Previously you could type whatever gibberish you wanted into the formula bar, press OK, and receive a modal syntax error window. Closing the syntax error window would cause the hotkey config window to close as well, and your gibberish would be applied to the hotkey assignment.
This commit requires that a syntax error does not occur before accept() is called.
There are certain hotkeys that we absolutely want to be able to use
without being in-game. Presently, no hotkeys are recognized unless we
are in-game.
I've identified and moved the following hotkeys to be checked before the
HotkeyScheduler checks to see if the Core is running:
- Open
- Exit
- Start Recording
- Refresh Game List
Note that Play Recording should also be implemented here, however it
looks like there is no signal for a PlayRecording() function, so this
will have to be handled in a later PR once that signal is created and
implemented.
Previously, it was not clear where the boundary of the StickWidget was when interacting outside of the circle. This aims to restore the gray square present in the Wx-era.
I found it a little bit annoying that you can't start typing
the desired address immediately after opening the window.
Also getting rid of the window's ? button while I'm at it.
Léo Lam