Makes it possible to run the kmlmc.cmd compiler wrapper script from
Keyman Developer while debugging from source.
Adds a new class `TKeymanDeveloperPaths` which is similar to
`TKeymanPaths`, to provide a future single location for all Keyman
Developer path-related functions. There are a number scattered through
the source at present, e.g. in `RedistFiles.pas`, so this is just a
starting point.
Fixes#5695.
When the debugger is in single-step mode, reflects the value of option
stores at the time of the change rather than at the beginning of the
batch.
Fixes#5577.
This ensures that the touch layout file is marked as modified after
running Import From Layout in Keyman Developer, so that changes are
not lost when you save.
Fixes#5642.
Relates to #5013.
This adds support for viewing and setting keyboard options in the
debugger. This initial implementation does not have 100% coverage of
keyboard options; specifically:
1. keyboard options are not saved between debug sessions.
2. in single-step debugging, the keyboard options will be shown as
updated at the start of a keystroke batch, not when the rule which
calls `set()` is fired. This level of granularity is not currently
visible from the engine. It does not impact the correctness of the
rule processing, only the view of the current state of the keyboard
option.
I do not anticipate supporting either of those functions in 15.0.
This commit renames the existing `TfrmDebugStatus_Options` to
`TfrmDebugStatus_Platform`. I had originally planned to show both the
platform and keyboard options in the same debug status window, but for
space reasons I have split them. (I'm sorry if this makes reading the
PR a little more challenging.)
There is a significant amount of rewriting of kmxfileutils.pas and
debugkeyboard.pas. This extends support for working with kmx files and
modernises the code (e.g. using generics for list types).
Note in particular the `ExpandSentinel` function in kmxfileutils.pas.
This is copied from CompileKeymanWeb.pas but has different internal
references, so cannot be used as-is -- CompileKeymanWeb works with
intermediate object 'files' from the kmx compiler, whereas the debugger
works with final binary .kmx files which have a different in-memory
layout. It may be possible to unify this in future but that would
involve additional risk. (Seriously, I would probably prefer to rewrite
CompileKeymanWeb.pas in C++, Rust or TypeScript than to invest in
merging these two use cases.)
Relates to #5013.
Adds a debug status page to allow the user to select an alternative
platform so they can debug rules relating to those platforms which
are constrained by the `platform()` statement in the keyboard source.
Note that while touch platforms are listed here, there is not yet any
method of activating touch key events (e.g. `[T_foo]`). This
functionality is planned for a future update.
Relates to #5013.
If user presses F6 in the debugger (while not in run mode), will now
switch to editor view, and vice-versa.
Also fixes the inversion of the focus test in CEF so that focus controls
work correctly for web hosts.
Relates to #5013.
Hide the debug events panel by default, and add
a Tools menu item to make it visible for dev purposes
(Ctrl+Shift+click on Tools menu to view).
Relates to #5013.
This resolves the broken Test Mode with Keyman Core. Previously, Test
Mode just dumped the keyboard into Keyman for Windows, and let it do its
thing. Given that we no longer have the dependency on Keyman for
Windows, the Test window must use Keyman Core to process keystrokes, and
that means there are some differences in how Test Mode operates in 15.0:
* Behind the scenes, the Test mode is just the Debug mode with
breakpoints and single step disabled, and the Debug Status window
hidden
* Test mode requires debug information in the keyboard (see note below)
* You can always switch between Test and Debug mode
* Deadkeys are always shown in the debug window
Test Mode now requires debug information to be included in the keyboard
in order for deadkeys to be tracked correctly in the editor. While it
would be possible to remove the need for this, it does not add any
significant benefit to do so -- doing so would mean that the tester
would have less visibility into deadkeys, and complicate the Core
marker tracking in the debug window.
I considered removing Test Mode altogether, but it still feels like a
useful view for playing with a keyboard without all the debugging
paraphernalia cluttering the display. It's a little slower than full
native Keyman for Windows (aka the 14.0 Test Mode), because the debug
hooks are still running in the background, but it is quite usable.
Note the removal of `Application.ProcessMessages`. This resolves the
issue of keystrokes being swallowed by the debugger during
non-interactive debug runs, making rapid input work properly in both
Debug Mode and Test Mode.
Relates to #5013.
Before starting on new functionality in the debugger, I wanted to
cleanup a bunch of bits and pieces, including:
1. Correct handling of text selection and deletion
2. Refactor of character grid at bottom of debug window
3. Deadkey realignment after text changes
4. Correct tracking of cursor position between events
5. Handling a few destruction edge cases
Refactors visual keyboard import from kmx to use Keyman Core, and at the
same time removes any UI interactions or direct Windows dependencies
from the process.
Fixes#5440.
Currently, the behavior of `use()` and `match` for KeymanWeb compiled
keyboards is not identical to the Windows (or Core) behavior. The
example keyboard in #5440 generates 'foo' instead of 'abc' on web.
This fixes that by ensuring that `match` is not called when `use()` is
found in a group rule match.
