Fixes#10161.
Includes transition of existing options from registry to options.json,
and once options.json exists, will always read from that and ignore
registry. Was able to eliminate some of the legacy datatype usage for
several options. Reader/writer includes naive file lock retry to avoid
contention, which I am hopeful will be sufficient for our needs, given
the low chance of contention.
First part of addressing #10161 is to refactor the existing usage of the
registry values into the common KeymanDeveloperOptions unit. This was
mostly straightforward except for the changes to KeymanSentryClient,
which happens to be the most important part of this particular fix.
Relates to #9473.
Now that each compiler has a common interface, we can consolidate the
common code into BuildActivity. This makes it very easy to see where the
compiler calls have special cases, such as the model_info and
keyboard_info compilers (these are primarily for internal use, so the
special case work should not be a problem).
`outFile` is not a compiler option, and so it should not be a part of
the `CompilerBaseOptions` interface. This formally separates the
command-line options from the compiler options, which eliminates a
number of restrictive structures.
Relates to #9473.
Refactors the public API of ModelInfoCompiler to meet KeymanCompiler,
including moving file write responsibilities into the class itself.
`sources` has become a property of `options`, which is perhaps a slight
violation of the intent of the `init()` function being a one-time call,
as it means we'll need to instantiate an new class for each file we
compile. Given the use-case for the model_info compiler is almost
exclusively internal, I think this is acceptable. Tell me if you think
otherwise!
Relates to #9473.
Refactors the public API of KeyboardInfoCompiler to meet KeymanCompiler,
including moving file write responsibilities into the class itself.
`sources` has become a property of `options`, which is perhaps a slight
violation of the intent of the `init()` function being a one-time call,
as it means we'll need to instantiate an new class for each file we
compile. Given the use-case for the keyboard_info compiler is almost
exclusively internal, I think this is acceptable. Tell me if you think
otherwise!
Relates to #9473.
Refactors the public API of PackageCompiler and
WindowsPackageInstallerCompiler to meet KeymanCompiler, including
asyncing a bunch of functions, and moving file write responsibilities
into the classes themselves.
The classes were updated together in a single commit because
WindowsPackageInstallerCompiler depends on PackageCompiler, and needed
refactoring for the updated API access there anyway.
Most of the test cases needed only minor patching, but introducing the
`async init()` function has caused them to all be async. The
test-messages module has a slight functional change with the compile
process running completely rather than stopping on first message, which
meant we needed to add extra dummy fixtures to avoid other errors that
arose later in the compile process. The keyman.exe fixture is a text
file, not a Windows executable.
Relates to #9473.
Refactors the public API of LexicalModelCompiler to meet KeymanCompiler,
including asyncing a bunch of functions, and moving file write
responsibilities into the class itself. Removes top-level
`compileModel()` and `loadFromFilename()` functions, as you should now
use `LexicalModelCompiler` API.
Most of the test cases needed only minor patching, but introducing the
`async init()` function has caused them to all be async, despite the
model compiler itself having no async requirements. I think this is
fine, because it makes any future additional async initialization tasks
much less painful to implement.
Relates to #9473.
Refactors the public API of LdmlKeyboardCompiler to meet KeymanCompiler,
including asyncing a bunch of functions, and moving file write
responsibilities out of kmc and into kmc-ldml.
Part of #9473.
KmnCompiler now implements KeymanCompiler, including the returned
artifacts. Also establishes the common types for the compiler interfaces
and consolidates and renames various API surfaces for kmc-kmn.
Fixes#10138.
If the current instance of Keyman Developer already has a project open,
then the New Project dialog will now open the new project in a new
instance of Keyman Developer.
Note: this also moves a couple of functions out of dmActionsMain and
into UfrmMain, as their functionality belongs more closely there. The
`TmodActionsMain.OpenProject` function has been renamed to
`TfrmMain.OpenProjectInCurrentProcess` to clarify its usage and context.
Fixes#10148.
We now force the SourcePath and BuildPath project properties to be a
direct subfolder of the project folder, in order to avoid issues with
paths in the future. This is only applied to v2.0 projects, and only
enforced via the UI at this point.
Fixes#10146.
Some developers may wish to stick with kpj-1.0 for now, and the prompt
to upgrade would annoying because it cannot be hidden. This resolves
that.
Note that I haven't at this point renamed UrlRenderer.pas, although it
may be worth considering in the future.
Fixes#10145.
Turns out we were clobbering out internal data because Delphi strings
are copy-on-write. At the same time, moved from using the Hint property
to just referencing the source filename in the array, as that is cleaner
anyway.
Fixes#10144.
Also adds .keyboard_info, for now, although it is removed in 17.0, as
there will be numerous projects which still have a .keyboard_info and
it is handy to be able to load it and view its contents while upgrading.
Fixes#10003.
Multiple small fixes required here:
* Add .kpj as an editable file type
* Ensure that when OpenFile returns nil (which it always will for a
.kpj), that we don't crash
* Ensure that projects open in a new process rather than replacing the
current project session
Adds a TODO for New Project -- this should be opened in a new process if
we already have a project open in the current process. Will push this
into a separate PR.
Refactor the file-opening code so it can be used by Keyman Developer UI
as well as command-line, and then add support for opening files in
per-project instances from File|Open and friends.
Also moves the initialization code out of tike.dpr into
Keyman.Developer.System.Main.pas, which makes it easier to maintain and
read.
This is a bit of an omnibus commit, apologies for that. This commit
moves Keyman Developer to a proper multi-process model, where editing
files from multiple projects is handled much more cleanly, with each
project loaded in a separate process.
Files that are edited outside of a project structure are loaded into a
'temporary project' in a single process, which provides a pathway for
existing users who may have legacy files outside the normal Keyman
Developer project model.
There are several components to this:
1. Inter-process communication (Multiprocess, CopyDataHelper units and
multiprocess test project). These modules establish a method of
enumerating running Keyman Developer instances (with EnumWindow),
recording relevant metadata for each instance (by thread id) in the
registry (registry used because it manages contention without
additional effort from us), and communicating between processes with
WM_COPYDATA.
2. Command-line parsing (TikeCommandLine). Determines project ownership
(ProjectOwningFile) for each filename passed on the command-line, and
passes these over to existing instances of Keyman Developer that have
that project loaded, or starts new instances as needed.
3. Temporary project management. Mostly in ProjectUI.
Also, moved GlobalProjectStateWnd management out of ProjectFile.pas and
into Project.pas, alongside other global project variables.
A follow-up will add functionality to determine if a file opened within
the Keyman Developer UI should open in the same instance or in a
separate instance (see TfrmKeymanDeveloper.OpenFileInProject). This will
use the same methodology as TikeCommandLine does now, so may involve
further refactoring.
This commit establishes the idea of 'keyman.kpj' as a future default
filename for Keyman Developer projects, but does not enable it, in
ProjectOwningFile. It is planned to introduce this fixed filename in
version 18.0 (see #10113).
Reverts some of the version 2.0 project functionality, as there are a
number of challenges around populating files for folders that don't have
project definitions, particularly if user attempts to load a folder that
is not a project folder after all but happens, e.g. to have a source
folder in it.
