Simplify editor and run command-line-arguments

Sauermann commented 1 year ago

Describe the project you are working on

Godot itself

Describe the problem or limitation you are having in your project

During testing MRPs and PRs I often have to change how I start godot. In order to start the Godot Editor or run a project the following command line parameters have to be used:

godot PathToProject/project.godot
godot --path PathToProject

godot PathToProject opens the ProjectManager and godot --path PathToProject/project.godot simply aborts.

The problems with the current parameters are:

For switching between the editor and running a project, I have to change both, the path (adjust "/project.godot") and the parameter --path.
Specifying project.godot for starting the editor seems to be redundant, because that name never changes.
Using --path as a parameter to run a project is not very intuitive. --run or --start would be better suited.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I would like, that a project could be run by either of

godot --run PathToProject
godot --run PathToProject/project.godot

and that the project could be loaded in the editor by either of

godot PathToProject
godot PathToProject/project.godot
godot --editor PathToProject
godot --editor PathToProject/project.godot

This would simplify the process for switching between running the project and starting the editor.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

To implement this proposal there would be two parts:

Interpreting PathToProject in the same way as PathToProject/project.godot (both for running the project and for starting the editor)
Adding --run as an alternative or replacement to --path

If this enhancement will not be used often, can it be worked around with a few lines of script?

no

Is there a reason why this should be core and not an add-on in the asset library?

Command line parameters seem to be core.

YuriSizov commented 1 year ago

godot --path <your_path> runs the project, godot -e --path <your_path> opens it in the editor. You only need to add or remove -e (or --editor).

As for godot <path/to/project.godot> this is likely needed for file association to work, even if it seems redundant. So I guess there is no issue then?

YuriSizov commented 1 year ago

Closing then.

JohanAR commented 1 year ago

Petition to reopen this proposal. I think it would be a nice QOL fix to accept a project dir path without explicitly adding the -e and --path options. I don't see any point in making things more complicated than they need to be.

It ought to be fairly easy to test if a non-option argument is a directory, and in that case if it contains a project.godot file. Perhaps this could even be a suitable first task for someone who wants to get involved in Godot development?

Sauermann commented 1 year ago

I would need assistance from the admins, because I can't reopen this issue myself.

YuriSizov commented 1 year ago

That's a very superficial "complication".

JohanAR commented 1 year ago

It just feels unnecessary and a bit counter-intuitive. I think it's pretty standard that running "./ " on a command line opens said thing in that program, which Godot also does as long as that something is a project.godot or scene file. This is how I expect all programs to work, so I wouldn't have thought it was an unintentional side-effect of file associations, though you might of course have more information about the intent of the original implementation than I do.

Since I don't think it's possible to have multiple Godot projects in the same folder, I don't see why there's any benefit to forcing the user to add "/project.godot", or having to remember the "-e --path" options. From my perspective, the folder containing all the files is a "project" which is why I expect Godot to accept it as a command line argument, but perhaps others see it differently.

I understand if you think this is too unimportant for yourself or other core developers to spend time on, but I don't understand why you're opposed to some random contributor implementing this. Or have I misunderstood the purpose of godot-proposals, and everything here goes into your backlog? Could a contributor just implement this and submit a PR without going through proposals?

Calinou commented 1 year ago

One downside to accepting a positional folder argument as an runnable (or editable) project is that you can't use a folder path as a command line argument in applications anymore. We could make it work only if the folder contains a project.godot file, but in this case, this will prevent folders containing project.godot files from being used as positional CLI arguments in exported projects.

YuriSizov commented 1 year ago

@JohanAR You still need -e/--editor, as otherwise you would run the project instead of editing it.

I understand if you think this is too unimportant for yourself or other core developers to spend time on, but I don't understand why you're opposed to some random contributor implementing this. Or have I misunderstood the purpose of godot-proposals, and everything here goes into your backlog? Could a contributor just implement this and submit a PR without going through proposals?

The purpose of the maintainer review is not to determine if we want to implement it ourselves, but to determine if the suggestion makes sense, solves a problem, fits the overall engine design, etc. Anyone can work on a feature if it matches the criteria.

This proposal can be reopened by the author if they still think it's relevant. But the original message was based on a wrong assumption that there are two incompatible ways to run and edit projects. In reality one of the ways was supporting all the options, while the other way was more limited indeed. As such, the engine already has a solution for the presented problem. If you think there is a reason to add extra support to the other syntax, it's another matter. We can discuss it, but it would be harder to justify the change when there is already a viable solution.

JohanAR commented 1 year ago

@YuriSizov and @Calinou thanks for the explanations, I just didn't understand the reason for why this was rejected based on your previous comments. It seemed like pretty trivial thing, and I had no idea that this would also affect exported projects.

Is it ok to continue the discussion here, since it's a similar suggestion even though the motivation is different? If not, disregard the rest of this post.

./bin/godot.linuxbsd.editor.dev.x86_64 ~/Code/godot4/color_picker_test/project.godot Opens the project in the editor, it does not run it, at least on Linux. I use it all the time, and sometimes I forget "/project.godot" at the end and then it opens the project browser just as if the positional argument wasn't there.

And if I'm allowed to be fastidious, my "problem" is that the syntax for opening a project from the command line is unnecessarily verbose, there is no solution to that :)

Well, you don't need to spend more time on this, you probably have more important decisions to make. I thought it would take about 2 lines of code to implement, and that it would not affect anything outside of being slightly more forgiving when opening a project. It's definitely not something important.

YuriSizov commented 1 year ago

Opens the project in the editor, it does not run it, at least on Linux.

Yep, and that's another indications that this was done only for the file association to work. Since otherwise the default behavior is to run the project, with editing being opt-in.

I use it all the time, and sometimes I forget "/project.godot" at the end

I mean, if you want to (intentionally) supply a directory instead of a file path, most tools that come to my mind would ask you to add an argument, like -d or something similar. So making our executable support both without any switching argument would not be a common practice, IMO.

I think the path to project.godot should work with everything, while the path to a directory is an extra feature for some cases.

and then it opens the project browser just as if the positional argument wasn't there.

We do plan to make it err if you supply invalid arguments, instead of ignoring them and defaulting to some behavior or another, but it's actually surprisingly tricky to make work. There were a few attempts.

JohanAR commented 1 year ago

Yep, and that's another indications that this was done only for the file association to work. Since otherwise the default behavior is to run the project, with editing being opt-in.

Maybe getting a bit off-topic, but is this something that others often do? Personally I've only used the Godot binary to edit projects.

I mean, if you want to (intentionally) supply a directory instead of a file path, most tools that come to my mind would ask you to add an argument, like -d or something similar.

I was thinking primarily about other IDEs, for example both these do the same thing, i.e. open the project for editing:

clion my_project
clion my_project/CMakeLists.txt

I suppose most generic programs, e.g. a media player, there's a conceptual difference between opening a folder and a file. Or in some cases it wouldn't make sense at all to open a folder, e.g. a simple text editor.

Sauermann commented 1 year ago

Unfortunately I can't reopen this issue. For Issues, that I closed myself, I see a "Reopen"-button. For this issue, I don't see that button, because I didn't close it.

Thanks for the info about command line arguments for exported projects. I wasn't aware of that detail.

When I created the proposal, I also tried to implement it and can confirm that it is not a trivial task and would require additional functionality in the form of additional command-line-flags.

One additional use-case, that I can think of is, that drag-n-drop from the file-explorer doesn't work, when I drop the directory onto the executable. (On Windows which doesn't have file-name completion in the shell, I find it sometimes easier to d-n-d the project) This proposal would allow as a QOL-feature dropping the directory directly, and make additional steps unnecessary (leaving the previous project-directory, entering the new project-directory).

Zireael07 commented 1 year ago

@Sauermann only original poster or organization members can reopen the issue. Here, I think Calinou and Yuri can

YuriSizov commented 1 year ago

Maybe getting a bit off-topic, but is this something that others often do? Personally I've only used the Godot binary to edit projects.

That's how your exported projects work. The executable by default tries to run the project in the same folder (in the .pck file). In the same way you can point it to a different folder containing a project. You have to remember that Godot is basically one executable, be it the editor build or export templates, with slightly different code branches being included or excluded. The basic functionality is still the same.

godotengine / godot-proposals