Set Workspace as default sidebar tab and add status bar - #26
Merged
Conversation
Addresses two user-feedback requests. Workspace as the default sidebar tab: WorkbenchDockFactory now lists the Workspace panel first in the left ToolDock and sets it as the initially active dockable, so a freshly launched application shows the workspace tree rather than Predefined Views. This matches the View menu, which already lists Workspace first. No layout persistence exists, so nothing can defeat the new default. Status bar: the main window gains a bottom status bar summarizing the active document tab - file name and full path for a source-text tab, and the view kind plus the entities being viewed for a diagram tab (capped at three names with a "+N more" elision), falling back to "Ready" when no tab is open. The summary is computed by MainWindowShell.GetActiveTabStatusSummary, which returns a plain string and keeps the shell free of any Avalonia dependency; MainWindowView binds it on tab-change and focus-change. Focus forwarding now covers source-text documents as well as diagrams, so NotifyActiveDiagramTab is renamed NotifyActiveDocumentTab. Test isolation: UiTests share a single headless Avalonia dispatcher, so assembly-level test parallelization is disabled to stop concurrent classes pumping each other's queued UI work. The new focus test drives Dock the way a real tab click does (activate then focus), since SetFocusedDockable is a no-op on a redundant focus request. Companion design, requirements, verification, README, and user guide artifacts are updated accordingly. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The activate-then-focus passage added in fde5a6f prescribed exercising tab selection by assigning the realized DocumentTabStrip.SelectedItem rather than calling the factory's SetActiveDockable/SetFocusedDockable. Every test in the repository does the opposite, so the design document contradicted the code it described. Describe the activate-then-focus pair the tests actually use - which is the same sequence Dock's own tab-header click handler issues - and record why focusing alone is insufficient. Found by formal review of the OTS-Dock review set. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
appium-novawindows-driver 1.4.2 reintroduced an inverted return value in trySetForegroundWindow: it returns the result of the Win32 EnumWindows call that locates the window, but EnumWindows returns FALSE precisely when its callback halts enumeration - that is, when the window was found and foregrounded. attachToApplicationWindow therefore takes its focusElement fallback on every successful launch, UI Automation SetFocus() throws against a window that already holds the foreground, and the launch loop swallows the error and retries 20 times before reporting "Failed to locate window of the app." Every Appium session fails, so all 10 Windows integration tests fail in CI. Confirmed by bisect and by patching that one function. Because the install was unpinned, CI went red on an unchanged commit the day 1.4.2 was published. Pin both CI and build.ps1 to 1.4.1, the last good release. build.ps1 also uninstalls a mismatched version first, since appium driver install refuses to overwrite an existing driver and both scripts tolerate its "already installed" error - without that, a stale local driver would silently defeat the pin and let local results diverge from CI. Remove the pins once a fixed release ships. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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
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.
This pull request introduces two main user-facing improvements to the SysML2Workbench application: (1) the workspace panel is now always the default sidebar tab shown at startup, and (2) a new status bar summarizes the currently active document tab at the bottom of the main window. The documentation and requirements/specifications have been updated throughout to reflect these changes, and related naming has been clarified from "diagram tab" to "document tab" where appropriate.
UI/UX Improvements:
API and Event Handling:
NotifyActiveDiagramTabtoNotifyActiveDocumentTab, reflecting that both diagram and source-text tabs are now tracked. All related documentation and requirements references have been updated accordingly. [1] [2] [3] [4] [5] [6]Requirements and Verification Documentation:
Technical Documentation:
MainWindowShellhave been added, specifying exactly how summaries are generated and when they update. [1] [2] [3] [4]These changes improve the application's usability by making the workspace immediately accessible and by giving users clear, always-visible feedback about the currently active document.