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

Extend output file format and folder selection #9

Closed
martinrieder opened this issue May 21, 2024 · 7 comments
Closed

Extend output file format and folder selection #9

martinrieder opened this issue May 21, 2024 · 7 comments
Milestone

Comments

@martinrieder
Copy link

Please extend the option for selecting the output format and folder. Especially the GV file is not generated by default since WV 0.4, though it might be required for debugging.

It seems sufficient to me if only a single file is generated and displayed in the preview panel. Even HTML output could be shown instead of the pictures.

Since this extension is called "wireviz-preview", it may be an option to generate the files in some temporary folder that might be deleted after closing the file.

@nanangp
Copy link
Owner

nanangp commented May 21, 2024

I could add a multiple-choice option for the user to select other formats to generate in the out dir, though I'm not sure how much it will impact the generation time (wouldn't be worse than at 0.3 when it was generating all of them).

Also thinking we should always generate the SVG to preview on the panel (eventually may even not be needed if/when WV implements direct STDOUT output). There's no more need to preview PNG on the panel, as it was only introduced as a workaround for a bug in the SVG output (#3) fixed by 0.4. Note: HTML is just an SVG wrapped inside a <html> tag.

@martinrieder
Copy link
Author

martinrieder commented May 22, 2024

@nanangp wrote:

I could add a multiple-choice option for the user to select other formats to generate in the out dir, though I'm not sure how much it will impact the generation time (wouldn't be worse than at 0.3 when it was generating all of them).

Sounds okay to me, though only a single file would be needed to preview. I would prefer the speedy way. You might add a simple option to append a string to the command line. If users want all files to be generated, they could simply request it there.

Also thinking we should always generate the SVG to preview on the panel (eventually may even not be needed if/when WV implements direct STDOUT output).

The users should still have a choice on what to display by default. Maybe let them easily switch without opening the extension settings. The question is: Would the picture be regenerated whenever the user is switching? Or would you pre-generate different files and let the user choose?

There's no more need to preview PNG on the panel, as it was only introduced as a workaround for a bug in the SVG output (#3) fixed by 0.4.

Some users would still prefer PNG because it is supported by most applications.

Note: HTML is just an SVG wrapped inside a <html> tag.

With the addition of a BOM and title block, as in Demo02.

The output folder for the preview could be temporary, especially in the case that users open files from a read-only location. Would you also add an option to delete the generated files after closing?

@martinrieder martinrieder changed the title Extend output file format selection Extend output file format and folder selection May 22, 2024
@nanangp
Copy link
Owner

nanangp commented May 23, 2024

Some users would still prefer PNG because it is supported by most applications.

I think we're overcomplicating this. All I'm saying is, for the preview panel we'll only use the SVG. If they want a PNG, HTML, GV, whatever output, they can specify it in the optional "other formats to generate" setting mentioned. We just won't be previewing them in the panel.

I never envisioned this extension to do output file management, with it being a previewer. The original idea was to not output anything and simply use stdout. If anyone wants to generate specific outputs, they can just specify a launch.json for their project, and launch WV with any parameters they want without this extension being involved in any of it.

@nanangp nanangp added this to the v1.1.0 milestone May 24, 2024
@nanangp
Copy link
Owner

nanangp commented May 24, 2024

Closing this with v1.1.0 that should now allow users to specify values for the command-line args.

@nanangp nanangp closed this as completed May 24, 2024
@martinrieder
Copy link
Author

I fully agree with you on the point that a preview extension should be kept simple. Thanks for hearing my suggestions though...
I just want to leave one last hint to a Blog post by @cooked on this topic: https://github.com/cooked/cooked.github.io/blob/refs%2Fheads%2Fmain/_posts%2F2023-09-16-vscode_wireviz.md

@nanangp
Copy link
Owner

nanangp commented May 30, 2024

Haha yeah, that post was what got me started. I used it for about a year. GV-interactive was (still is) a brilliant extension, and it also being GPL-3.0 opens the door for us to maybe one day integrate it (though it is significantly heavier than a simple svg previewer).

This extension was an exercise of, "Never done a vscode extension before, let's see how far we can push it". Also a first foray into the Node/Typescript ecosystem.
Never expected anyone else would use it, much less care enough to raise actual bugs and feature requests... So thank you.

@martinrieder
Copy link
Author

martinrieder commented Jun 7, 2024

@nanangp posting into this closed issue to simply let you know of an idea I am pursuing:

The HTML output could be enriched by https://github.com/mountainstorm/jquery.graphviz.svg

EDIT alternative https://github.com/w8r/leaflet-schematic

I am mostly missing the zoom functionality, though this provides a few other options as well.

Taking the thought a bit further, it would allow nodes or edges to be highlighted, in case that WireViz reports an issue.

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