-
Notifications
You must be signed in to change notification settings - Fork 3
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
Export current scene as mp4 #38
Comments
UI: File pickerFor the file picker, see this API. We could use that to let users specify a location where to save their file. UI: Trigger exportUsers somehow have to trigger the export command. Invoking it from the command palette is probably not the best choice.
UI: Define settings for exportUsers could define settings in a multi-step quick pick. If that gets too long, we might want to use a custom webview view even if that is discouraged by VSCode. But they don't specify what you should use instead then since they also advise against using multi step quick picks to create wizards (see my comment). And in the Webview UI toolkit there are some nice elements that we could use like a dropdowns, checkboxes etc. |
Maybe you could also vote for this issue at VSCode since they look for issues with high votes to organize their backlog. I think it'd be really cool to be able to use |
After just revisiting this again: Yes, I think it'd be cool to have a general feature for export. But it's probably really tedious if we want to support every option that So what do you think about this approach: provide a very basic UI where the most important settings (image quality and fps) can be set. Then, let the user click on a button like This approach has some advantages:
So far I was always pro-UI à la "Let us support a terminal-free workflow". But totally terminal-free is unrealistic I guess. Users will have to interact with it anyways:
And for the export, I actually see the advantages of the terminal as being very flexible and giving the power to the user. But of course, maybe I'm just making up an excuse to not implement all the shell parsing ;) Let me know what you think. I just want to avoid the situation where we get PRs like "Add this or that as export option", which would be a bit annoying IMHO as I'd rather invest my time in getting the core things right, which is the preview itself (and niceties centered around it). Maybe we should then develop a policy, e.g. that we close such PRs because we only support image quality and fps via the UI. |
I fully approve this workflow. It is more than sufficient for a v0.1.0 release. If we wanted to get fancy down the road, we could automatically parse the |
Ah, good idea haven't thought about that. However, in the end it's not as easy as just populating checkboxes based on this. Every single step needs custom validation and custom tuning, e.g. sometimes allow users to input a number greater than x, sometimes a number in a range, sometimes with decimals, sometimes without, sometimes allow a string with a dot in the end, sometimes not, sometimes add a custom validation text, sometimes enable/disable a step based on a previous input etc. That's just to say that every new option we would like to add there needs custom care and maintenance efforts. I just don't want to spend too much time on this and tailor to every user and every obscure export setting that Manim might offer. The few essential ones like quality and fps, yes, but I don't envisage to expand on this in any way ;) Users still have the option to add their custom flags in the terminal in the pasted command. |
We are very close to a full pipeline for Manim development. Crucially, we are missing the final step of actually exporting a scene as an e.g., mp4 of some quality (a thought I came up with as I was writing the "sales pitch demo" #37 for this extension)
At the minimum, we want to expose a command that lets users choose the following from the
manimgl
tool:(happy to discuss more advanced options like
Gif?
,Transparent?
,background color?
, etc., but I was hoping to appeal to the broadest user that would care about the quality of the mp4 they were generating)Finally, let the user choose which file to save the output video to
The text was updated successfully, but these errors were encountered: