Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenEvent should be more robust #129

Open
pascalwilbrink opened this issue Jul 14, 2023 · 1 comment
Open

OpenEvent should be more robust #129

pascalwilbrink opened this issue Jul 14, 2023 · 1 comment

Comments

@pascalwilbrink
Copy link
Member

pascalwilbrink commented Jul 14, 2023

As a Engineer
I want to be able to open non SCL files while keeping the current SCL file open

Background
If we want to make use of helper documents (Like XSD, NSD, NSDOC files), we need to make the OpenEvent more robust.
Currently, if the OpenEvent is emitted and is picked up by OpenSCD Core, The "docName" is set directly as the docName. This means that Docs that are opened via the OpenEvent, will always be the current document that is being edited. This is a side effect that causes problems.

For helper Files, this should not be the case.

We can have multiple solutions for this

  • Split up Opening and Editing into 2 events
  • Add a flag to the OpenEvent
  • Add a fileType to the OpenEvent
@ca-d
Copy link
Contributor

ca-d commented Aug 15, 2023

Another possibility would be to have an array of editable file types as an attribute on the editor itself and let the distribution choose which opened files should be editable, then only switch to the opened file if it has an extension listed in the array. I have no strong preference for any of these solutions.

In the meantime, a hacky work-around solution for loading support documents would consist in checking if a document with that file name has already been loaded, and if not, add the document directly to the docs object.

Either way, well-known file names seem vital to dealing with supporting documents. Coming up with suitable conventions, especially as regards versioned files like schema and nsd files, would be an important task to solve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants