stride3d / stride3d/stride

Modify the concept of code assets in the editor

Open
#1,621 5 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
C#
Stars
7.8k
Forks
1.2k
Avg merge
2d 17h
Merged PRs (30d)
49

Description

Is your feature request related to a problem? Please describe.
Currently the editor iterates over all folders in a project to find C# source files and shows them under a Code folder in the project tree. Selecting that folder allows the user to browse files in the asset browser. The ScriptEditor is used to edit those c# files within the GameStudio.

One of caveats of this approach is that it focuses on source files as assets, when in many cases those files do not hold entities usable in the editor, other than for the purpose of text editing.

We've had issues (mostly around syntax highlighting) with the built in script editor before and while RoslynPad provides good usability it's not the same as using a fully fledged IDE. In my opion with Stride targeting C# developers it is often to be expected that the user would have VS/Rider installed and for those that don't we can encourage use of VS Code. Preferring use of external code editor means Stride has a smaller maintenance burden in this aspect.

Then there's the case of usability of code based assets. At the moment the primary engine entity extracted from code files is a ScriptComponent. There was recently a fix made to the drag-and-drop functionality of dragging a source file asset onto an entity in the scene to add the script component. From what I've seen there's an assumption made there that one C# file holds one script. It also missed the opportunity of allowing dragging over other types deriving from EntityComponent.

Describe the solution you'd like
If we were to leave larger code editing to an IDE, we can still keep the script editor for making minor single file scoped changes.
Those changes should focus on the code usable in the editor.

I propose dropping the source file view of code assets and transition to a component view where we extract usable types from the source files and present them in the asset view (keeping the source file chierarchy).

Editing a component (double clicking) would still open script editor as the file association would stay there.

There may be a bit to figure out how deleting the component from a source file is treated or how opening two components from one file should not open multiple editors.

Additional context
The asset structure in the asset browser

Code
    MyFolder
        MyScript.cs
        MyMultiScript.cs
    MyModel.cs
    MyEntityComponent.cs

Would become

Components
    MyFolder
        MyScript
        MyMulti1
        MyMulti2
    MyEntityComponent

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the editor's asset browser Code-folder discovery, ScriptEditor association, and source-file drag-and-drop behavior described in the issue. Define how usable component types are extracted and shown under Components, including multi-component files, deletion, and opening multiple components from one file; done means the proposed component view replaces the source-file view without losing editing or scene assignment.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
game-dev, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.