Modularize Editor#186
Open
foxnne wants to merge 49 commits into
Open
Conversation
Phase 3a
foxnne
force-pushed
the
push-nvyuxknzqxmr
branch
9 times, most recently
from
40af769 to
a416ec3
Compare
foxnne
force-pushed
the
push-nvyuxknzqxmr
branch
11 times, most recently
from
09c2933 to
f6a16c5
Compare
Allow ABI-version mismatches to reject loading plugin Handle loading config area plugins excersize 3rd party plugin Update build files for sdk simplify creating plugin work on rough edges Remove pixel art specific vtable hooks make pixel art specific hooks commands instead finish removing pixel art specifics in EditorAPI begin refining sdk unify builtin and 3rd party plugins split root refine plugin structure across all fix web build fix tab bar on bottom panel make core.gpa not have to be set by plugin authors Fix sprites panel small visual fixes, refresh api refine build.zig's in plugins begin work towards plugin store chunks 1 + 2 begin chunk 3 chunk 4 chunk 5 chunk 6 chunk 7 separate pixi from fizzy entirely Phase b1 b1b begin store_text_sidebar plan Phase 0 Phase 1-2 Phase 3-4 sdk: key ABI fingerprint lock by (arch, os) The comptime self-check in src/sdk/version.zig compared every native target's live structural fingerprint against a single hardcoded recorded_abi_fingerprint. The fingerprint hashes @offsetOf/@Alignof of the plugin-boundary types, which follows each target's C ABI, so aarch64-macos, x86_64-linux, and x86_64-windows legitimately produce different (but each internally valid) fingerprints for the same boundary. The check only exempted wasm32, so every non-aarch64-macos native build failed at compile time (surfaced as CI failures building the pixi plugin on linux/windows). Replace the single constant with a small per-(arch, os) table, recorded_abi_fingerprints, and look up the entry matching the target being built. Also corrects the aarch64-macos entry itself (0x1bb54eb7506cbd78 -> 0x9f75e41ec2f5c17f): it was already stale even for that one target on the current toolchain resolution, independent of the arch issue above -- caught because plugin_sdk=true only registers modules and never actually compiles them, so it had never been exercised by a real build. Verified via genuinely compiling pixi (a real third-party plugin, not the plugin_sdk export path) for aarch64-macos, x86_64-linux-gnu, and x86_64-windows-gnu, all clean. update fingerprint scheme update dvui refine store design plugin store work phase 5 sqlite update docs
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.
This PR is a large work in progress to discern information about the future of modularizing the editor.
This is the largest change to fizzy since rewriting in DVUI.
As of now, the proof of concept already works, with pending edits to DVUI to add a proxy backend, allowing us to compile individual libraries (plugins) which can be runtime loadable.
Currently, the app is now split into the following:
The editor itself is now often referred to as a shell, as it just reads plugins and renders their contributions to the correct regions.
- Handles rendering tabs and splits
- Basically all the functionality of fizzy originally, but contained to a plugin
- Support image loading and editing, adding supported docs to tabs/splits
- Basic text editing and syntax highlighting
The strategy here is to essentially statically link ALL builtin plugins for the web build. For the native build, we vendor a
pluginsfolder containing the dylibs the editor will read at runtime. We also look for plugins at the config location, so hopefully we can support 3rd party plugins sooner rather than later.Goals