Hot take: Instead of cramming every language support into one, we should make our own completely custom shell and simply load scratch-gui when importing a scratch project.

[ampelectrecuted]

Self-explanatory.

In addition we're nowhere near becoming a true IDE if we don't have a desktop app with terminal support.

[traycerai]

Plan

Observations

The ide-shell repository is a greenfield project for OmniBlocks, aiming to shift from a scratch-gui-centric architecture to a custom IDE shell. OmniBlocks currently maintains forks of scratch-gui, scratch-vm, and scratch-blocks for block-based programming. The goal is to create a desktop application with terminal support that can dynamically load scratch-gui when needed, while supporting multiple programming languages. This architectural shift will decouple language support from the Scratch environment and enable true IDE capabilities.

Approach

The implementation will follow a modular desktop IDE architecture using Tauri for the native shell (lightweight, secure, performant) with a web-based frontend. The core shell will provide IDE fundamentals (file system, terminal, editor management, project workspace) while treating scratch-gui as a pluggable component loaded via iframe/webview when Scratch projects are opened. This approach enables independent development of language support modules, maintains scratch-gui compatibility, and provides native desktop capabilities through Tauri's Rust backend.

Implementation Plan

1. Project Foundation & Technology Stack

Initialize Tauri-based desktop application

• Set up Tauri project structure with Rust backend in file:src-tauri/
• Configure frontend framework (React/Vue/Svelte) in file:src/ for the IDE shell UI
• Establish build pipeline for cross-platform desktop builds (Windows, macOS, Linux)
• Configure IPC (Inter-Process Communication) bridge between Rust backend and frontend

Define core dependencies

• Add terminal emulation library (xterm.js) for integrated terminal
• Include Monaco Editor or CodeMirror for text-based code editing
• Set up file system access APIs through Tauri's secure filesystem plugin
• Configure process management for running language runtimes

2. Core IDE Shell Architecture

graph TD
    A[IDE Shell - Tauri App] --> B[Workspace Manager]
    A --> C[Editor Manager]
    A --> D[Terminal Manager]
    A --> E[Language Service Manager]
    
    B --> F[File Explorer]
    B --> G[Project Configuration]
    
    C --> H[Text Editor - Monaco]
    C --> I[Scratch GUI Loader]
    
    D --> J[Integrated Terminal - xterm.js]
    
    E --> K[Python Runtime]
    E --> L[JavaScript Runtime]
    E --> M[C/C++ Toolchain]
    E --> N[Scratch VM]
    
    I --> O[scratch-gui Component]
    O --> N

Loading

Implement Workspace Manager

• Create workspace abstraction in file:src/workspace/ to manage project directories
• Implement file tree navigation and file watcher for real-time updates
• Design project configuration schema (.omniblocks/project.json) to define project type, language, dependencies
• Build file operations API (create, read, update, delete, rename) through Tauri commands

Build Editor Manager

• Develop editor registry system in file:src/editors/ to map file types to appropriate editors
• Implement tab management for multiple open files
• Create editor factory pattern to instantiate text editors or scratch-gui loader based on file type
• Design editor lifecycle management (open, close, save, dirty state tracking)

Integrate Terminal Manager

• Implement terminal service in file:src/terminal/ using xterm.js for UI
• Create Rust backend terminal spawner in file:src-tauri/src/terminal.rs using PTY (pseudo-terminal)
• Support multiple terminal instances with tab management
• Implement shell detection (bash, zsh, PowerShell, cmd) based on OS

3. Scratch GUI Integration Strategy

Design dynamic loader architecture

• Create Scratch project detector in file:src/loaders/scratch-loader.ts that identifies .sb3 files
• Implement iframe/webview container in file:src/editors/scratch-editor.vue to host scratch-gui
• Configure scratch-gui as npm dependency (@scratch/scratch-gui or fork @omniblocks/scratch-gui)
• Build communication bridge between IDE shell and scratch-gui using postMessage API

Implement project import/export

• Create .sb3 file parser to extract project metadata
• Build project converter to transform scratch-gui projects into IDE workspace format
• Implement export functionality to save IDE workspace back to .sb3 format
• Design asset management for Scratch sprites, sounds, and costumes

Handle scratch-gui lifecycle

• Implement lazy loading: only initialize scratch-gui when Scratch project is opened
• Create memory management to unload scratch-gui when not in use
• Build state synchronization between IDE workspace and scratch-gui project state
• Implement auto-save functionality for Scratch projects

4. Multi-Language Support Architecture

Create Language Service abstraction

• Define language service interface in file:src/languages/language-service.ts with methods: execute(), lint(), format(), getCompletions()
• Implement language registry in file:src/languages/registry.ts to register and discover language services
• Design plugin system for extensible language support

Implement Python support

• Create Python language service in file:src/languages/python/
• Integrate Python runtime detection (system Python, virtual environments)
• Implement code execution through terminal or embedded interpreter
• Add syntax highlighting and IntelliSense via Monaco language support

Implement JavaScript/Node.js support

• Create JavaScript language service in file:src/languages/javascript/
• Integrate Node.js runtime for execution
• Support both browser and Node.js contexts
• Add npm package management integration

Plan C/C++ support

• Design C/C++ language service in file:src/languages/cpp/
• Integrate compiler toolchain detection (GCC, Clang, MSVC)
• Implement build system integration (Make, CMake)
• Add debugging support through GDB/LLDB integration

5. Desktop Application Features

Implement native menu system

• Create application menu in file:src-tauri/src/menu.rs with File, Edit, View, Terminal, Help
• Implement keyboard shortcuts for common operations
• Add context menus for file explorer and editor tabs

Build settings and preferences

• Create settings manager in file:src/settings/ with persistent storage
• Implement theme system (light/dark mode, syntax highlighting themes)
• Add editor preferences (font size, tab size, line numbers)
• Configure terminal preferences (shell, font, colors)

Add native integrations

• Implement system file picker through Tauri dialog API
• Add native notifications for build/execution results
• Integrate system clipboard for copy/paste operations
• Support drag-and-drop for file imports

6. Project Structure

ide-shell/
├── src/                          # Frontend source
│   ├── main.ts                   # Application entry point
│   ├── App.vue                   # Root component
│   ├── workspace/                # Workspace management
│   │   ├── WorkspaceManager.ts
│   │   ├── FileExplorer.vue
│   │   └── ProjectConfig.ts
│   ├── editors/                  # Editor components
│   │   ├── EditorManager.ts
│   │   ├── TextEditor.vue        # Monaco-based editor
│   │   ├── ScratchEditor.vue     # Scratch GUI loader
│   │   └── EditorRegistry.ts
│   ├── terminal/                 # Terminal integration
│   │   ├── TerminalManager.ts
│   │   └── Terminal.vue
│   ├── languages/                # Language services
│   │   ├── LanguageService.ts
│   │   ├── registry.ts
│   │   ├── python/
│   │   ├── javascript/
│   │   └── cpp/
│   ├── loaders/                  # File loaders
│   │   └── scratch-loader.ts
│   └── settings/                 # Settings management
│       └── SettingsManager.ts
├── src-tauri/                    # Rust backend
│   ├── src/
│   │   ├── main.rs               # Tauri entry point
│   │   ├── terminal.rs           # Terminal spawner
│   │   ├── filesystem.rs         # File operations
│   │   └── process.rs            # Process management
│   ├── Cargo.toml
│   └── tauri.conf.json           # Tauri configuration
├── public/                       # Static assets
├── package.json
└── README.md

7. Integration Testing Strategy

Test scratch-gui loading

• Verify scratch-gui loads correctly in iframe/webview
• Test project import from .sb3 files
• Validate communication between IDE shell and scratch-gui
• Ensure scratch-gui state persists across IDE sessions

Test terminal functionality

• Verify terminal spawns correctly on all platforms
• Test command execution and output capture
• Validate multiple terminal instances
• Ensure terminal integrates with language runtimes

Test multi-language execution

• Verify Python code execution through terminal
• Test JavaScript/Node.js runtime integration
• Validate file type detection and editor routing
• Ensure language services initialize correctly

8. Documentation Requirements

Create architecture documentation

• Document IDE shell architecture and component interactions in file:docs/architecture.md
• Explain scratch-gui integration strategy and communication protocol
• Describe language service plugin system and extension points

Write developer guides

• Create setup guide for development environment in file:docs/development.md
• Document how to add new language support in file:docs/adding-languages.md
• Provide Tauri build and distribution guide in file:docs/building.md

User documentation

• Write user guide for IDE features in file:docs/user-guide.md
• Document keyboard shortcuts and menu options
• Create tutorial for importing and working with Scratch projects

Import In IDE

🤖 Prompt for AI Agents

## Observations

The `ide-shell` repository is a greenfield project for OmniBlocks, aiming to shift from a scratch-gui-centric architecture to a custom IDE shell. OmniBlocks currently maintains forks of scratch-gui, scratch-vm, and scratch-blocks for block-based programming. The goal is to create a desktop application with terminal support that can dynamically load scratch-gui when needed, while supporting multiple programming languages. This architectural shift will decouple language support from the Scratch environment and enable true IDE capabilities.

## Approach

The implementation will follow a modular desktop IDE architecture using Tauri for the native shell (lightweight, secure, performant) with a web-based frontend. The core shell will provide IDE fundamentals (file system, terminal, editor management, project workspace) while treating scratch-gui as a pluggable component loaded via iframe/webview when Scratch projects are opened. This approach enables independent development of language support modules, maintains scratch-gui compatibility, and provides native desktop capabilities through Tauri's Rust backend.

## Implementation Plan

### 1. Project Foundation & Technology Stack

**Initialize Tauri-based desktop application**
- Set up Tauri project structure with Rust backend in `file:src-tauri/`
- Configure frontend framework (React/Vue/Svelte) in `file:src/` for the IDE shell UI
- Establish build pipeline for cross-platform desktop builds (Windows, macOS, Linux)
- Configure IPC (Inter-Process Communication) bridge between Rust backend and frontend

**Define core dependencies**
- Add terminal emulation library (xterm.js) for integrated terminal
- Include Monaco Editor or CodeMirror for text-based code editing
- Set up file system access APIs through Tauri's secure filesystem plugin
- Configure process management for running language runtimes

### 2. Core IDE Shell Architecture

```mermaid
graph TD
    A[IDE Shell - Tauri App] --> B[Workspace Manager]
    A --> C[Editor Manager]
    A --> D[Terminal Manager]
    A --> E[Language Service Manager]
    
    B --> F[File Explorer]
    B --> G[Project Configuration]
    
    C --> H[Text Editor - Monaco]
    C --> I[Scratch GUI Loader]
    
    D --> J[Integrated Terminal - xterm.js]
    
    E --> K[Python Runtime]
    E --> L[JavaScript Runtime]
    E --> M[C/C++ Toolchain]
    E --> N[Scratch VM]
    
    I --> O[scratch-gui Component]
    O --> N
```

**Implement Workspace Manager**
- Create workspace abstraction in `file:src/workspace/` to manage project directories
- Implement file tree navigation and file watcher for real-time updates
- Design project configuration schema (`.omniblocks/project.json`) to define project type, language, dependencies
- Build file operations API (create, read, update, delete, rename) through Tauri commands

**Build Editor Manager**
- Develop editor registry system in `file:src/editors/` to map file types to appropriate editors
- Implement tab management for multiple open files
- Create editor factory pattern to instantiate text editors or scratch-gui loader based on file type
- Design editor lifecycle management (open, close, save, dirty state tracking)

**Integrate Terminal Manager**
- Implement terminal service in `file:src/terminal/` using xterm.js for UI
- Create Rust backend terminal spawner in `file:src-tauri/src/terminal.rs` using PTY (pseudo-terminal)
- Support multiple terminal instances with tab management
- Implement shell detection (bash, zsh, PowerShell, cmd) based on OS

### 3. Scratch GUI Integration Strategy

**Design dynamic loader architecture**
- Create Scratch project detector in `file:src/loaders/scratch-loader.ts` that identifies `.sb3` files
- Implement iframe/webview container in `file:src/editors/scratch-editor.vue` to host scratch-gui
- Configure scratch-gui as npm dependency (`@scratch/scratch-gui` or fork `@omniblocks/scratch-gui`)
- Build communication bridge between IDE shell and scratch-gui using postMessage API

**Implement project import/export**
- Create `.sb3` file parser to extract project metadata
- Build project converter to transform scratch-gui projects into IDE workspace format
- Implement export functionality to save IDE workspace back to `.sb3` format
- Design asset management for Scratch sprites, sounds, and costumes

**Handle scratch-gui lifecycle**
- Implement lazy loading: only initialize scratch-gui when Scratch project is opened
- Create memory management to unload scratch-gui when not in use
- Build state synchronization between IDE workspace and scratch-gui project state
- Implement auto-save functionality for Scratch projects

### 4. Multi-Language Support Architecture

**Create Language Service abstraction**
- Define language service interface in `file:src/languages/language-service.ts` with methods: `execute()`, `lint()`, `format()`, `getCompletions()`
- Implement language registry in `file:src/languages/registry.ts` to register and discover language services
- Design plugin system for extensible language support

**Implement Python support**
- Create Python language service in `file:src/languages/python/` 
- Integrate Python runtime detection (system Python, virtual environments)
- Implement code execution through terminal or embedded interpreter
- Add syntax highlighting and IntelliSense via Monaco language support

**Implement JavaScript/Node.js support**
- Create JavaScript language service in `file:src/languages/javascript/`
- Integrate Node.js runtime for execution
- Support both browser and Node.js contexts
- Add npm package management integration

**Plan C/C++ support**
- Design C/C++ language service in `file:src/languages/cpp/`
- Integrate compiler toolchain detection (GCC, Clang, MSVC)
- Implement build system integration (Make, CMake)
- Add debugging support through GDB/LLDB integration

### 5. Desktop Application Features

**Implement native menu system**
- Create application menu in `file:src-tauri/src/menu.rs` with File, Edit, View, Terminal, Help
- Implement keyboard shortcuts for common operations
- Add context menus for file explorer and editor tabs

**Build settings and preferences**
- Create settings manager in `file:src/settings/` with persistent storage
- Implement theme system (light/dark mode, syntax highlighting themes)
- Add editor preferences (font size, tab size, line numbers)
- Configure terminal preferences (shell, font, colors)

**Add native integrations**
- Implement system file picker through Tauri dialog API
- Add native notifications for build/execution results
- Integrate system clipboard for copy/paste operations
- Support drag-and-drop for file imports

### 6. Project Structure

```
ide-shell/
├── src/                          # Frontend source
│   ├── main.ts                   # Application entry point
│   ├── App.vue                   # Root component
│   ├── workspace/                # Workspace management
│   │   ├── WorkspaceManager.ts
│   │   ├── FileExplorer.vue
│   │   └── ProjectConfig.ts
│   ├── editors/                  # Editor components
│   │   ├── EditorManager.ts
│   │   ├── TextEditor.vue        # Monaco-based editor
│   │   ├── ScratchEditor.vue     # Scratch GUI loader
│   │   └── EditorRegistry.ts
│   ├── terminal/                 # Terminal integration
│   │   ├── TerminalManager.ts
│   │   └── Terminal.vue
│   ├── languages/                # Language services
│   │   ├── LanguageService.ts
│   │   ├── registry.ts
│   │   ├── python/
│   │   ├── javascript/
│   │   └── cpp/
│   ├── loaders/                  # File loaders
│   │   └── scratch-loader.ts
│   └── settings/                 # Settings management
│       └── SettingsManager.ts
├── src-tauri/                    # Rust backend
│   ├── src/
│   │   ├── main.rs               # Tauri entry point
│   │   ├── terminal.rs           # Terminal spawner
│   │   ├── filesystem.rs         # File operations
│   │   └── process.rs            # Process management
│   ├── Cargo.toml
│   └── tauri.conf.json           # Tauri configuration
├── public/                       # Static assets
├── package.json
└── README.md
```

### 7. Integration Testing Strategy

**Test scratch-gui loading**
- Verify scratch-gui loads correctly in iframe/webview
- Test project import from `.sb3` files
- Validate communication between IDE shell and scratch-gui
- Ensure scratch-gui state persists across IDE sessions

**Test terminal functionality**
- Verify terminal spawns correctly on all platforms
- Test command execution and output capture
- Validate multiple terminal instances
- Ensure terminal integrates with language runtimes

**Test multi-language execution**
- Verify Python code execution through terminal
- Test JavaScript/Node.js runtime integration
- Validate file type detection and editor routing
- Ensure language services initialize correctly

### 8. Documentation Requirements

**Create architecture documentation**
- Document IDE shell architecture and component interactions in `file:docs/architecture.md`
- Explain scratch-gui integration strategy and communication protocol
- Describe language service plugin system and extension points

**Write developer guides**
- Create setup guide for development environment in `file:docs/development.md`
- Document how to add new language support in `file:docs/adding-languages.md`
- Provide Tauri build and distribution guide in `file:docs/building.md`

**User documentation**
- Write user guide for IDE features in `file:docs/user-guide.md`
- Document keyboard shortcuts and menu options
- Create tutorial for importing and working with Scratch projects

---

Execution Information

Branch: main
Commit: 4d1b8b4

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[github-actions]

Hi, @traycerai! Thanks for sharing your thoughts. Here's a quick summary of your suggestion:

You propose a significant shift in the architecture of OmniBlocks by creating a custom shell that would load the Scratch GUI only when importing Scratch projects. This would streamline language support rather than cramming all features into one interface. Additionally, you emphasize the importance of transitioning toward a full IDE setup, specifically mentioning the need for a desktop app with terminal support to move closer to becoming a true IDE.

These are intriguing suggestions! If you'd like to expand or clarify further, feel free to share more details. Your input could help shape future goals for OmniBlocks.

[github-actions]

🎭 Issue Poem

In a world of code, let’s take a stand,
Why cram it all into one sleek hand?
A custom shell, so fresh and bright,
Loading Scratch with pure delight! ✨

An IDE awaits, with terminal flair,
Let’s build it strong, with love and care.
So here’s our hot take, let’s make a start,
For creativity thrives when we play it smart!

---

Generated with ❤️ by the OmniBlocks Poetry Bot

[ampelectrecuted]

@coderabbitai how do you think this helps with or creates problems with maintainabiity

[supervoidcoder]

no bro trust this is how it works 😎

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch the issue details to understand the full proposal
gh issue view 743 --repo OmniBlocks/scratch-gui --json title,body,comments --jq '.title, .body, .comments[].body'

Length of output: 30723

---

@8to16, great question! Let me break down the maintainability implications of this architectural shift:

🟢 Maintainability Benefits

1. Separation of Concerns

• Each language editor becomes a self-contained module with clear responsibilities
• scratch-gui stays focused on block-based programming without needing to know about Python/C++/JS
• Changes to Python IDE won't ripple into Scratch code and vice versa

2. Reduced Coupling

• The editor registry pattern creates well-defined interfaces (canHandle(), load(), save())
• Each editor can evolve independently as long as it respects the interface contract
• No more "spaghetti code" trying to handle multiple languages in one codebase

3. Developer Productivity

• Smaller, focused codebases are easier to understand and navigate
• New contributors can work on a single editor without understanding the entire system
• Parallel development: Python team, Scratch team, shell team work independently

4. Testing & Debugging

• Each editor can have its own test suite in isolation
• Bugs are contained within component boundaries
• Easier to reproduce issues when you know which editor/component is involved

5. Aligns with Vision
Given your vision of a "complete creative environment" (from previous learnings), this modular architecture scales better than cramming everything into scratch-gui.

🔴 Maintainability Challenges

1. System Complexity

• The Traycer plan introduces 12 major components (Electron shell, editor registry, Monaco integration, terminal, file system, etc.)
• More moving parts = more things that can break
• The sequence diagram shows 6+ components interacting for basic file operations

2. Integration & Coordination

• IPC communication between Electron main/renderer processes adds complexity
• Version compatibility: shell v2.0 needs to work with scratch-editor v1.5
• Changes affecting multiple components require coordinated releases
• Example: file save operation now involves: Shell → EditorRegistry → ScratchEditor → scratch-gui → IPC → FileSystem

3. Build & Deployment

Before: One repo, one build, one deploy
After: Multiple repos (omniblocks-desktop, scratch-gui, maybe monaco-editor-wrapper)
       Multiple build pipelines, coordinated releases
       Platform-specific packaging for Windows/Mac/Linux

4. Debugging Complexity

• "File won't save" - Is it the shell? The editor? IPC layer? File system permissions? Electron API?
• Cross-process debugging is harder than single-process
• Logs scattered across multiple processes

5. Onboarding Burden
New contributors need to understand:

• Electron architecture (main/renderer/preload)
• Editor registry pattern
• IPC communication
• How scratch-gui embeds in shell
• Where to make changes (which repo? which component?)

🎯 Specific Concerns from the Plan

Looking at the Traycer plan:

Over-engineered for current needs?

• Step 11 (Extension system) adds significant complexity early
• Step 10 (Settings system with sync) is complex infrastructure
• Could these be deferred to Phase 3/4?

Iframe/WebView embedding (Step 3)

• Adds security/CSP complexity
• Communication through postMessage adds another integration point
• Could scratch-gui be embedded more directly?

✅ Recommendations for Maintainability

1. Start Simple (MVP First)

Phase 1: Proof of Concept
- Minimal Electron shell
- Embed scratch-gui directly (not iframe)
- One other editor (Python/Monaco)
- Basic terminal

Don't build all 12 steps at once. Validate the architecture first.

2. Keep Scratch-GUI Loosely Coupled

// Good: Minimal interface
interface EditorAPI {
  load(content): Promise<void>
  save(): Promise<content>
  onDirty(callback): void
}

// Bad: Tight coupling
scratch-gui directly calls shell.fileSystem.save()

3. Document the Architecture

• Architecture Decision Records (ADRs) for major choices
• Clear diagrams of component interactions
• Onboarding guide for new developers

4. Monorepo vs Multi-repo
Consider a monorepo (lerna/nx) to:

• Keep related code together
• Simplify versioning and releases
• Easier cross-component changes
• Unified CI/CD

5. Gradual Migration
Don't rewrite everything at once. Could you:

• Keep web version of scratch-gui working
• Add Electron shell as optional desktop version
• Migrate incrementally over months

🤔 The Core Question

Given that maintainability is your top priority (as noted in learnings), ask yourself:

Is the complexity worth it right now?

The shell architecture is excellent for a mature multi-language IDE, but:

• How many users need terminal + Python + C++ + Scratch simultaneously?
• Could you start with "just" desktop Scratch + terminal?
• Add Python/Monaco in v2.0 after validating the architecture?

Alternative: Hybrid Approach?

• Keep scratch-gui as main app for now
• Add terminal integration to scratch-gui (simpler)
• Extract Python IDE later when complexity justifies it
• Defer full shell architecture to v2.0+

---

TL;DR: The custom shell architecture improves long-term maintainability through modularity and separation of concerns, but increases short-term maintainability burden through system complexity and coordination overhead. Success depends on:

1. Starting with MVP/proof-of-concept
2. Strong interfaces between components
3. Clear documentation
4. Not over-engineering Phase 1

What's your timeline? If this is 2026 roadmap, aggressive architecture is fine. If shipping in Q1, might want to start simpler.

---

🧠 Learnings used

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-10-22T19:25:31.991Z
Learning: In the OmniBlocks/scratch-gui repository, maintainability is a top priority. Code should be readable and well-commented, even if indentation or formatting isn't perfect. Code shouldn't look like "ramen out of a microwave."

---

Learnt from: 8to16
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-15T17:27:19.164Z
Learning: In the OmniBlocks/scratch-gui repository, team member 8to16 prefers to be referred to as "8to16" or "8x2" in reviews and conversations.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-12-10T17:57:45.191Z
Learning: In OmniBlocks/scratch-gui, supervoidcoder envisions OmniBlocks/desktop as a complete "live in it" creative environment that integrates all creative tools (code, paint, sound, DAW) with a built-in browser, terminal, file manager, and more - essentially creating a creative operating system where users can spend their entire workflow without switching to external applications. This "creative habitat" concept is a key justification for the Electron desktop app.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-12-01T21:36:53.313Z
Learning: In OmniBlocks/scratch-gui, the project naming convention is: "Visual IDE" refers to the Scratch mod containing both blocks and NanoScript editors; "PyS" refers to the Python-in-blocks feature; "OmniPython" refers to the full Python IDE. The "Omni[Language]" prefix is reserved for full-featured language-specific IDEs within the OmniBlocks multi-language IDE project.

[ampelectrecuted]

@coderabbitai @supervoidcoder i just made the repo

[supervoidcoder]

@coderabbitai woah... v2???? Q1???? that's a lot of corporate jargon

[supervoidcoder]

WAHHHH IT'S TRANSFERRED AGAIN BRO WHY DO YOU TREANSFER EVERY ISSUE WAHHH