Proj structure - #681
Open
TheJoeFin wants to merge 7 commits into
Open
Conversation
Phase 0 of the v5 workflow engine roadmap: adds the class-library split (pure Core, Windows-TFM Core.Windows) and a fast pure-unit-test project that later phases will move logic into, with no production code moved yet. Both new libraries needed explicit RuntimeIdentifiers matching the app so the MSIX wapproj restores project references per-RID.
Phase 1 of the v5 workflow engine roadmap: StringMethods.cs was already a pure extension-method class with only System.* dependencies, making it a zero-risk first move. It needed CurrentCase and SpotInLine, so those two enums are split out of Text-Grab/Enums.cs into Text-Grab.Core/Enums.cs (same Text_Grab namespace, no using changes needed anywhere); the rest of Enums.cs stays in the app since those enums are UI/settings concerns. Tests/StringMethodTests.cs is left in place unchanged - it still compiles and passes via the transitive Tests -> Text-Grab -> Text-Grab.Core reference chain. It wasn't moved to Tests.Core because one test (TestReverseString) exercises StringBuilderExtensions.ReverseWordsForRightToLeft, which lives in a separate app-side file not covered by this move.
…Core Continuing Phase 1 of the v5 workflow engine roadmap. Both were already pure (BCL-only usings), making them straightforward moves alongside StringMethods. TextSearchUtilities was internal, visible to the app only through the same-assembly rule and to Tests via Text-Grab's InternalsVisibleTo. Once it moved to Core it's a different assembly from its main consumers (FindAndReplaceWindow, GrabFrame, EditTextWindow), so internal no longer fit; made it public instead, matching StringMethods/CharacterUtilities.
Continuing Phase 1. Scoped to RecognizerExecutor only this round - PatternExecutor stays in the app since PatternItem.GetAll()/GetByName() are wired to the settings singleton, which would cascade into a wider refactor (splitting PatternItem, updating ~6 UI call sites). Both RecognizerExecutor and PatternExecutor called into GrabTemplateExecutor.ExtractMatchesByMode, an internal pure method buried in an otherwise WPF/OCR-coupled 660-line class. Extracted just that method (+ its ExtractByIndices helper) into a new Text-Grab.Core MatchModeSelector so RecognizerExecutor doesn't need to reach back into the app; GrabTemplateExecutor and PatternExecutor now call the Core version too, removing the duplicate logic instead of leaving it behind. Added Microsoft.Recognizers.Text.* package references (+ the existing NuGet.CommandLine exclusion workaround) to Text-Grab.Core, and dropped the now-redundant direct references from Text-Grab.csproj since they flow in transitively through the project reference.
Continuing Phase 1. StoredRegex.cs was already fully pure, so it moved
as-is. PatternItem.cs needed a real split: the class/PatternKind enum are
pure, but its GetAll()/GetByName() static methods are wired to
AppUtilities.TextGrabSettingsService (the settings singleton).
- Text-Grab.Core keeps the PatternItem class (properties + internal
constructors + PatternKind enum) - no settings dependency.
- New Text-Grab/Models/PatternItemCatalog.cs (staying app-side) carries
GetAll()/GetByName(), unchanged apart from the new name.
- Added InternalsVisibleTo("Text-Grab") and InternalsVisibleTo("Tests")
to Text-Grab.Core so PatternItemCatalog and RegexManager.xaml.cs (which
also constructs PatternItem directly) can still reach the internal
constructors, and so Tests/PatternExecutorTests.cs (which constructs
PatternItem directly for deterministic fixtures) still compiles.
- Updated every PatternItem.GetAll()/GetByName() call site to
PatternItemCatalog: SearchBar, TextOnlyTemplateDialog,
SplitColumnWindow, EditTextWindow, GrabFrame, and the test file.
PatternExecutor.cs stays in the app for now - this split is what
unblocks moving it next.
First move into Core.Windows, starting Phase 4 of the v5 workflow engine roadmap. Both are pure interface contracts (ILanguage needs Windows.Globalization, IOcrLinesWords/IOcrLine/IOcrWord need Windows.Foundation.Rect) with zero implementation logic and zero WPF coupling - the Windows SDK projections resolve automatically from the net10.0-windows10.0.22621.0 TFM, no extra package needed. No consumer call sites needed touching: implementers (TessLang, GlobalLang, WinRtOcrLinesWords, etc.) stay in the app and keep resolving the interfaces transitively through the existing project reference.
Continuing Phase 4. Moved the clean tier identified after mapping the whole OCR/HDR area: TessLang, GlobalLang, WinAiOcrLinesWords (all already dependency-free beyond ILanguage/IOcrLinesWords, which moved earlier), and WinRtOcrLinesWords. WinRtOcrLinesWords needed one fix: its constructor called OcrUtilities.GetBoundingRect() - an app-side extension method that computes the union of a line's word rects but returns a WPF System.Windows.Rect, which the constructor then converted back into a WinRT Windows.Foundation.Rect. Since every input (OcrWord.BoundingRect) is already a WinRT Rect, that was a pointless WPF round-trip and the actual blocker to moving the file. Replaced it with a local private helper that computes the same union directly in Windows.Foundation.Rect. OcrUtilities.GetBoundingRect itself is untouched - other app code may still use it. Also extracted HocrReader + TessOcrLine (the last ~53 lines of TesseractHelper.cs) into Text-Grab.Core - pure string/regex hOCR parsing, already cleanly separated from the rest of the file, going to plain Core (not .Windows) since it's not Windows-specific. The rest of TesseractHelper.cs stays in the app; nothing else currently calls it. Added Microsoft.WindowsAppSDK.AI to Text-Grab.Core.Windows.csproj for WinAiOcrLinesWords' RecognizedText/RecognizedLine/RecognizedWord types. Deferred (each documented in the plan with its specific blocker): OcrUtilities.cs (the actual "pivotal cut" - 1061 lines, mixed headless/UI-adapter code plus a hidden WPF dependency in LoadBitmapFromFile), the TesseractHelper class itself (settings-write side effect in GetTesseractPath), LanguageService.cs and WindowsAiUtilities.cs (both settings+WPF coupled, each dragging in several more untouched types), BarcodeUtilities.cs (blocked on OcrOutput.CleanOutput() reading settings directly), and the HDR/WGC capture code (separate area, mostly clean already).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
organize pure logic out into a .core project and windows related features into a .windows project