Add functionality to open blend files from editor

[SamuelBilek]

• Open blend file from right click context menu in file explorer
• Open multiple blend files from the command palette

[Mateusz-Grzelinski]

hm, there are things that I like and things that i dont like:

• open blend file with right click - great
• so you are proposing to make command like Blender: Start but one which can choose file interactively? I did not go into the details in code. I do not like it. It has potential to conflict with user settings.
  • instead I would much rather finally create a launch config which can be saved, reused and triggered with shortcut. I did not have time do it at all as I am focused on 184. I think there is an option to generate such config interactively. If not, we can always make a notification that can save the command used.

[SamuelBilek]

I based the interactive opening of files on the work of my colleagues, as they work with addons that can use hundreds of blend files but each day they work only on a few of them throughout the day. Sometimes they need to have several blend libraries opened at once. This command was meant to ease up the workflow where you have to open some version of Blender for each library you want to open. This way, you choose everything you want and select the Blender executable only once.

Also, the right-click open uses most of the functionality of the command you don't like, so I am not sure how go about it 😅 I get your concern that this could mess with user settings, but from my testing, Blender always opens the last file it was provided in the launch args, so users would keep their other settings (except file-launch-related args like --open-last) and only the launched file would change. I'm not sure I completely understand your idea with the config, but I might have something similar on my mind. What if we create a new config for args that should be used while opening files with commands (both right click and interactive)? This way users keep their original args when they use the vanilla Blender: Start and they have a different set of args for file launching?

[Mateusz-Grzelinski]

Yah, I get it.
We mainly need to solve design of blender.additionalArguments

• create separate blender.openFileAdditionalArguments
• parsing blender.additionalArguments in order to find errors: problematic statements: --, --open-last. I those are the main ones to watch

Originally I wanted to propose:

• add marker like <file.blend> in vs code which will be replaced with the path of the file to be opened. If marker is not present report error when using command

but it seems that it will not work as Blender has non-posix argument handling:

> blender--help
Argument Order:
        # blender --background --render-output /tmp test.blend --render-frame 1
        ...will not render to '/tmp' because loading the blend-file overwrites the render output that was set.

What introduces SO MANY corner cases that it makes my head hurt... I dont wan to deal with it today.

Sometimes they need to have several blend libraries opened at once

You mean that vs code should be aware about those blender instances?

[SamuelBilek]

I would prefer to have a separate config for opening files. We don't have to check for --open-last as blender skips it, if there's another file to open later in args. We can add information to the README about this new set of args and disclose the limitations that options that change stuff in the opened file and passing arguments with -- won't work.

Yes I think vscode should be aware of those instances, so you can see how each blend file interacts with your addons from vscode.

Sorry to make your head hurt, don't worry about this too much. This was my first time working in typescript and vscode extension development as a part of a creative project and I don't need to push it quickly 😸

[SamuelBilek]

In the new commit I added two new lists of arguments that mimic the preFileArgs and postFileArgs in the command line pattern blender [preFileArgs ...] [file] [postFileArgs]. This way we split the args passed during regular Blender: Start and the commands for opening blend files, while users still have control over which arguments are passed before the file and which are passed after.

[Mateusz-Grzelinski]

i see where you are going. I propose a little twist: lets make 2 options:

• keep the blender.additionalArguments
• create new options blender.pythonArguments (or blender.additionalPythonArguments)

Create a blender command using logic (pseudo code):

if " -- " in blender.additionalArguments and blender.pythonArguments: # finding -- in blender.additionalArguments  needs refinement
  raise error
if normal launch:
  blender.additionalArguments  + "--" + blender.pythonArguments
if run with file:
  blender.additionalArguments + <file to open> + "--" + blender.pythonArguments
  # i think we also need 
  if " -- " in blender.additionalArguments:
    raise error

Reason:

• maintain backwards compability with little change
• pre and post is confusing for user - programs usually accept argument once. I am sneakly changing pre to additionalArguments and post to additionalPythonArguments
• and it seems to work "good enough": I can think of several ways to break it but user will need to learn blender cmd oddities.

Is it better, or just confusing?

[SamuelBilek]

I think this is more limiting to for the user than my approach:

• You want to use already existing additionalArguments as pre, but you want to throw error when -- is found, which can create conflict if they already use the arguments for opening blender with Blender: Start
• pythonArguments gives a hint that it should be used only for python-related args but that's not true. We want them for all args that can be passed after a filename, but especially for args that use and modify the opened file (output filepath, render X frames, etc...).

We could mix our approaches:

• let the already existing additionalArguments serve as pre args and filter out args after -- instead of throwing errors. Blender will filter out the file related args on its own if we pass it a new file in later args.
• Find a more suitable name for the postArguments and use them after opening the file

Since we would be mixing old with new, I think we could maybe go one step further and put the new postArguments always to the end of the launchArgs. My reasons:

• It won't break backwards compatibility
• Users can move their post-file-related args from additionalArguments there so they have don't have to have them defined in two places.
• I think we can assume the user knows a bit about blender cli arguments if they are using our args, so we can assume they know the pattern blender [args...] [file] [args...]. I would even go as far as creating a standalone filepathToOpen arg to sandwich between additionalArgs and postArgs if it's present, but that might be too much.

What do you think about these ideas? :)

[Mateusz-Grzelinski]

Oh, ok, I was not aware about all all the details, I will think about it.
But I am starting to think that separate option blender.openFileAdditionalArguments with obligatory file marker might be our best option.

[SamuelBilek]

Hello! Did you come to a conclusion what to do here? :)

[Mateusz-Grzelinski]

I still think the blender.openFileAdditionalArguments with obligatory file marker might be our best option.

I am in the middle of trips, in next 2 weeks I will not be available much, sorry. 🤸