kindred/create
1
1
Fork 0
Code Issues 53 Pull Requests Actions Packages Projects 9 Releases 2 Wiki Activity

Epic: Unified File Origin System #8

New Issue
Closed
opened 2026-02-05 18:23:48 +00:00 by forbes · 1 comment
forbes commented 2026-02-05 18:23:48 +00:00
Owner
Copy Link

Overview

Replace the current dual command system (standard FreeCAD file operations + Silo workbench commands) with a unified origin-based architecture. Users select their file origin (Local Files, Silo instances) from a dropdown, and all file operations work contextually based on that selection.

Key Insight: Origins don't change where files are stored—all documents are always saved locally. Origins change the workflow and identity model:

  • Local: Document identity = file path, no external tracking
  • Silo: Document identity = part number, syncs with database/MinIO, files cached locally

Problem Statement

Currently, Kindred Create has two parallel file operation systems:

  1. Standard FreeCAD: Std_New, Std_Open, Std_Save → local filesystem
  2. Silo Workbench: Silo_New, Silo_Open, Silo_Save → database + MinIO storage (with local cache)

This creates several UX issues:

  • Duplicate UI - Two sets of nearly identical commands/icons
  • Confusing mental model - Users must understand two parallel systems
  • Mode toggle is hidden - The Silo_ToggleMode button doesn't make it obvious which "mode" is active
  • No multi-instance support - Can only connect to one Silo instance at a time

Proposed Solution

Origin Selector Dropdown

A compact toolbar widget in the top-left that determines the workflow for file operations:

┌─────────────────────────────────────────────────────────────────┐
│ [☁️ Work ▼]  [New] [Open] [Save] [SaveAs] | [Commit] [Pull]...  │
└─────────────────────────────────────────────────────────────────┘
       │
       ▼
  ┌────────────────────┐
  │ ✓ ☁️ Work          │  ← Connected Silo instance
  │   ☁️ Production    │  ← Another Silo instance
  │   📁 Local Files   │  ← Always available
  │ ────────────────── │
  │   ⚙️ Manage...     │  ← Configuration dialog
  └────────────────────┘

Key Behavioral Differences

Operation Local Origin Silo Origin
New Create empty document Part creation form (category from schema YAML)
Open File picker dialog Database search pane with local cache status
Save Save to disk Save to disk + sync to MinIO
Save As File picker for new path Migration (if local) or Copy (if Silo) workflow
Identity File path Part number (SiloPartNumber property)

Silo's Hybrid Local-Remote Model

Silo documents are always stored locally in ~/projects/cad/{category}/{part_number}_{desc}.FCStd. The database and MinIO provide:

  • Part number assignment and metadata tracking
  • Revision history and cloud backup
  • Selective download (only needed files cached locally)

This means:

  • Open shows database items, downloads if not cached locally
  • Save writes locally first, then syncs to cloud (graceful offline)
  • Document ownership determined by SiloPartNumber property, not file path

Dynamic Toolbar

When a Silo origin is selected, additional Silo-specific commands appear:

  • Commit, Pull, Push, Info, BOM, Rollback, Status

When Local Files is selected, these commands are hidden.

Mixed Origin Workflows

Since all files are local, "mixed origin" means:

  • Migration: Add Silo tracking to a local document
  • Copy: Create new Silo item from existing Silo document
  • Export: Save Silo document without tracking (for sharing)

Multi-Instance Support

Users can configure multiple Silo instances with nicknames:

  • Work, Production, Staging, etc.
  • Each with independent API URL, credentials, SSL settings

Benefits

  1. Single set of commands - Familiar New/Open/Save work contextually
  2. Clear visual indicator - Always visible which workflow is active
  3. Multi-instance support - Connect to multiple Silo deployments
  4. Familiar pattern - Similar to VS Code remote, Google Drive folder selector
  5. No workbench dependency - Works from any workbench

Implementation Phases

Phase 1: Core Architecture

  • #9 Origin abstraction layer (interfaces, OriginManager)
  • #10 Local filesystem origin implementation
  • #11 Silo origin adapter

Phase 2: Command Integration

  • #12 Modify Std_* commands to delegate to current origin
  • #13 Origin selector toolbar widget
  • #14 Dynamic toolbar extension for Silo commands

Phase 3: Enhanced Features

  • #15 Multi-instance Silo configuration UI
  • #16 Document origin tracking and display
  • #17 Mixed origin workflows (migration, copy, export)

Migration Path

  • Existing Silo_ToggleMode preferences migrate automatically
  • First launch detects existing Silo config → creates default origin
  • Silo_* commands remain for backwards compatibility (delegate to OriginManager)

Design Principles

  • Minimal toolbar footprint (nickname display ~60-80px)
  • Keyboard shortcuts unchanged (Ctrl+O/S/N work with current origin)
  • Non-blocking origin switching
  • Clear connection status indication
  • Graceful offline handling for Silo origins (local save always works)
  • Document ownership by properties, not file path
## Overview Replace the current dual command system (standard FreeCAD file operations + Silo workbench commands) with a unified origin-based architecture. Users select their file origin (Local Files, Silo instances) from a dropdown, and all file operations work contextually based on that selection. **Key Insight**: Origins don't change where files are stored—all documents are always saved locally. Origins change the **workflow** and **identity model**: - **Local**: Document identity = file path, no external tracking - **Silo**: Document identity = part number, syncs with database/MinIO, files cached locally ## Problem Statement Currently, Kindred Create has two parallel file operation systems: 1. **Standard FreeCAD**: `Std_New`, `Std_Open`, `Std_Save` → local filesystem 2. **Silo Workbench**: `Silo_New`, `Silo_Open`, `Silo_Save` → database + MinIO storage (with local cache) This creates several UX issues: - **Duplicate UI** - Two sets of nearly identical commands/icons - **Confusing mental model** - Users must understand two parallel systems - **Mode toggle is hidden** - The `Silo_ToggleMode` button doesn't make it obvious which "mode" is active - **No multi-instance support** - Can only connect to one Silo instance at a time ## Proposed Solution ### Origin Selector Dropdown A compact toolbar widget in the top-left that determines the workflow for file operations: ``` ┌─────────────────────────────────────────────────────────────────┐ │ [☁️ Work ▼] [New] [Open] [Save] [SaveAs] | [Commit] [Pull]... │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────┐ │ ✓ ☁️ Work │ ← Connected Silo instance │ ☁️ Production │ ← Another Silo instance │ 📁 Local Files │ ← Always available │ ────────────────── │ │ ⚙️ Manage... │ ← Configuration dialog └────────────────────┘ ``` ### Key Behavioral Differences | Operation | Local Origin | Silo Origin | |-----------|--------------|-------------| | **New** | Create empty document | Part creation form (category from schema YAML) | | **Open** | File picker dialog | Database search pane with local cache status | | **Save** | Save to disk | Save to disk + sync to MinIO | | **Save As** | File picker for new path | Migration (if local) or Copy (if Silo) workflow | | **Identity** | File path | Part number (`SiloPartNumber` property) | ### Silo's Hybrid Local-Remote Model Silo documents are **always stored locally** in `~/projects/cad/{category}/{part_number}_{desc}.FCStd`. The database and MinIO provide: - Part number assignment and metadata tracking - Revision history and cloud backup - Selective download (only needed files cached locally) This means: - **Open** shows database items, downloads if not cached locally - **Save** writes locally first, then syncs to cloud (graceful offline) - Document ownership determined by `SiloPartNumber` property, not file path ### Dynamic Toolbar When a Silo origin is selected, additional Silo-specific commands appear: - Commit, Pull, Push, Info, BOM, Rollback, Status When Local Files is selected, these commands are hidden. ### Mixed Origin Workflows Since all files are local, "mixed origin" means: - **Migration**: Add Silo tracking to a local document - **Copy**: Create new Silo item from existing Silo document - **Export**: Save Silo document without tracking (for sharing) ### Multi-Instance Support Users can configure multiple Silo instances with nicknames: - Work, Production, Staging, etc. - Each with independent API URL, credentials, SSL settings ## Benefits 1. **Single set of commands** - Familiar New/Open/Save work contextually 2. **Clear visual indicator** - Always visible which workflow is active 3. **Multi-instance support** - Connect to multiple Silo deployments 4. **Familiar pattern** - Similar to VS Code remote, Google Drive folder selector 5. **No workbench dependency** - Works from any workbench ## Implementation Phases ### Phase 1: Core Architecture - [x] #9 Origin abstraction layer (interfaces, OriginManager) - [x] #10 Local filesystem origin implementation - [x] #11 Silo origin adapter ### Phase 2: Command Integration - [x] #12 Modify Std_* commands to delegate to current origin - [x] #13 Origin selector toolbar widget - [x] #14 Dynamic toolbar extension for Silo commands ### Phase 3: Enhanced Features - [x] #15 Multi-instance Silo configuration UI - [x] #16 Document origin tracking and display - [x] #17 Mixed origin workflows (migration, copy, export) ## Migration Path - Existing `Silo_ToggleMode` preferences migrate automatically - First launch detects existing Silo config → creates default origin - `Silo_*` commands remain for backwards compatibility (delegate to OriginManager) ## Design Principles - Minimal toolbar footprint (nickname display ~60-80px) - Keyboard shortcuts unchanged (Ctrl+O/S/N work with current origin) - Non-blocking origin switching - Clear connection status indication - Graceful offline handling for Silo origins (local save always works) - Document ownership by properties, not file path
forbes commented 2026-02-05 22:51:18 +00:00
Author
Owner
Copy Link

All phases complete. Closing with code references:

Phase 1 — Core Architecture:

  • src/Gui/FileOrigin.h / .cpp — Origin abstraction layer + LocalFileOrigin (#9, #10)
  • src/Gui/OriginManager.h / .cpp — Singleton origin manager (#9)
  • src/Gui/FileOriginPython.h / .cpp — Python wrapper for Silo adapter (#11)

Phase 2 — Command Integration:

  • src/Gui/CommandDoc.cpp:83-119,650-805 — Std_New/Open/Save/SaveAs delegate to current origin (#12)
  • src/Gui/OriginSelectorWidget.h / .cpp — Toolbar dropdown widget (#13)
  • src/Gui/CommandOrigin.cpp — Origin_Commit/Pull/Push/Info/BOM commands (#14)
  • src/Gui/Action.cpp:1476-1493 — OriginSelectorAction toolbar integration

Phase 3 — Enhanced Features:

  • src/Gui/OriginManagerDialog.h / .cpp — Multi-instance config UI (#15)
  • src/Gui/MDIView.cpp:520-534 — Document origin display in window title (#16)
  • src/Gui/CommandDoc.cpp:780-804 — Mixed origin Save As workflows (#17)

All files registered in src/Gui/CMakeLists.txt. Sub-issues #9–#17 all implemented.

All phases complete. Closing with code references: **Phase 1 — Core Architecture:** - `src/Gui/FileOrigin.h` / `.cpp` — Origin abstraction layer + LocalFileOrigin (#9, #10) - `src/Gui/OriginManager.h` / `.cpp` — Singleton origin manager (#9) - `src/Gui/FileOriginPython.h` / `.cpp` — Python wrapper for Silo adapter (#11) **Phase 2 — Command Integration:** - `src/Gui/CommandDoc.cpp:83-119,650-805` — Std_New/Open/Save/SaveAs delegate to current origin (#12) - `src/Gui/OriginSelectorWidget.h` / `.cpp` — Toolbar dropdown widget (#13) - `src/Gui/CommandOrigin.cpp` — Origin_Commit/Pull/Push/Info/BOM commands (#14) - `src/Gui/Action.cpp:1476-1493` — OriginSelectorAction toolbar integration **Phase 3 — Enhanced Features:** - `src/Gui/OriginManagerDialog.h` / `.cpp` — Multi-instance config UI (#15) - `src/Gui/MDIView.cpp:520-534` — Document origin display in window title (#16) - `src/Gui/CommandDoc.cpp:780-804` — Mixed origin Save As workflows (#17) All files registered in `src/Gui/CMakeLists.txt`. Sub-issues #9–#17 all implemented.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
UX
branding
bug
ci/cd
CI/CD workflows and deployment
 defaults
documentation
Developer documentation
 enhancement
high-priority
low-priority
theme
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
forbes
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kindred/create#8
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?