Kx is a .NET 10 desktop UI/runtime framework with a plugin-driven window system, YAML-based markup, custom rendering, and a sample updater application built on top of it.
The repository now contains five main areas:
- reusable framework and runtime infrastructure in
src - concrete applications in
apps - reusable plugins in
plugins - tests in
tests - runnable reference material in
examples
src/Kx- framework runtime, window system, rendering, configuration loading, plugin infrastructuresrc/Kx.Sdk- contracts for plugins, UI, logging, DI, window hosting, and markupapps/KxUpdater- concrete updater application built on the framework, including its ownAssetscontent and the file-based updater clientapps/KxUpdateBuilder- desktop manifest builder for publishing file-based updates into anUploadfolderapps/KxUpdater/Plugins/KalTheme- updater-specific visual plugin scaffold for the KalOnline style and updater-specific UI worktests/Kx.Tests- framework and runtime teststests/KxUpdater.Tests- updater application tests
plugins- home for reusable plugins that are not tied to a single applicationplugins/KalCipher- reusable cipher pluginplugins/KalCipher.Tests- tests for the reusable cipher plugin
examples/Kx.Plugin.Example- reference plugin that registers controls, actions, commands, themes, and window definitionsexamples/Kx.Example.App- minimal sample host application that demonstrates the framework together with the example plugin and its own localAssetscontent
The codebase is being split more clearly into:
- framework-generic infrastructure in
Kx - app-specific behavior in
KxUpdater - reusable cross-app plugins under
plugins - app-specific plugins beside their owning app
- plugin extension points through
Kx.Sdk - learning and reference material under
examples
The runtime bootstrap is now composed explicitly through dedicated composition objects:
PluginRuntimeCompositionRuntimeUiCompositionRuntimeLoggingCompositionRuntimeShellComposition
This keeps RuntimeServiceConfiguration focused on registering already composed services instead of constructing them inline.
docs/architecture.md- project boundaries, runtime startup flow, and composition modeldocs/grid-splitter.md- runtime-resizable grid dividers, YAML usage, and layout recommendationsdocs/plugins.md- plugin model, registries, markup assets, and example plugin walkthroughdocs/update-builder.md- file-based updater publishing flow,KxUpdateBuilderusage, manifest structure, and IIS notesdocs/windows-and-markup.md- window lifecycle, YAML/registry lookup, control layers, icon precedence, and fallback UI behavior
Open the solution in Visual Studio 2026 or build from the repository root and run apps/KxUpdater.
Build and run apps/KxUpdateBuilder. It mirrors files from an Update folder into an Upload folder and writes a file-based update.json manifest for KxUpdater.
Build and run examples/Kx.Example.App. It is intended as the smallest reference host for the framework and the example plugin.
- framework/runtime tests:
dotnet test tests/Kx.Tests/Kx.Tests.csproj - updater app tests:
dotnet test tests/KxUpdater.Tests/KxUpdater.Tests.csproj - reusable plugin tests:
dotnet test plugins/KalCipher.Tests/KalCipher.Tests.csproj
- updater app startup:
apps/KxUpdater/Program.cs - update builder startup:
apps/KxUpdateBuilder/Program.cs - sample app startup:
examples/Kx.Example.App/Program.cs - runtime bootstrap:
src/Kx/App/Runtime.cs - base window behavior:
src/Kx/App/Window.cs - example plugin:
examples/Kx.Plugin.Example/Example.cs
KxUpdater now uses a file-based manifest flow instead of requiring a monolithic update.zip package.
Current publication model:
update.jsondescribes all current files plusdeletedFilesnews.yamlprovides updater news entries- each published file is downloaded directly from its relative path under the update base URL
Current client behavior:
- load
update.json - compare local file hashes against manifest entries
- download only changed or missing files
- remove files listed in
deletedFiles - stage a replacement updater executable for self-update when needed
Current builder behavior:
- read source files from
Update - mirror them into
Upload - remove legacy
update.zipandversion.txtartifacts fromUpload - write
update.json
For a practical walkthrough, see docs/update-builder.md.
Framework-generic path and loading infrastructure stays in Kx.
Concrete asset files belong to the owning app or example project. That includes:
Assets/Configs/app.yamlAssets/Configs/frame.yamlAssets/Languages/*.yaml- app-owned icons under
Assets/Icons - theme-owned visuals under
Assets/Themes/<ThemeName>/...
Resource ids map directly under the app Assets root. For example:
Icons:app.ico->Assets/Icons/app.icoThemes:KalOnline:Frame:top_left.png->Assets/Themes/KalOnline/Frame/top_left.pngThemes:KalOnline:Buttons:btn_exit.normal.png->Assets/Themes/KalOnline/Buttons/btn_exit.normal.png
Current examples:
- updater app assets now live under
apps/KxUpdater/AssetsAssets/Icons/app.icoAssets/Themes/KalOnline/Frame/...Assets/Themes/KalOnline/Buttons/...
- sample app assets now live under
examples/Kx.Example.App/AssetsAssets/Icons/app.ico
Kxkeeps generic asset resolution infrastructure, not updater-specific content files
- app-local plugins live beside their owning app, for example
apps/KxUpdater/Plugins/KalTheme - reusable plugins live under
plugins, for exampleplugins/KalCipher - app hosts include plugins through the shared MSBuild
PluginProject+build/PluginCopy.targetspattern - framework tests stay in
tests/Kx.Tests - app-specific tests stay in dedicated app test projects such as
tests/KxUpdater.Tests - reusable plugin tests stay beside the plugin under
plugins/<PluginName>.Tests
- plugin-driven UI extension
- YAML-defined windows and themes
- custom-rendered desktop UI
- explicit runtime composition
- separation between reusable framework code and app-specific code
This project is licensed under the GPL-3.0. See LICENSE.txt.