godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.16k stars 97 forks source link

Put the Documentation on a Completely Separate Tab #970

Closed ghost closed 4 years ago

ghost commented 4 years ago

Describe the project you are working on: 2D platformer. Describe the problem or limitation you are having in your project: Having the documentation in the same tab as Script is quite counter-intuitive and cumbersome, as each time you check a node or function, it adds it to your scripts area. Also, going back from reading documentation back to your script is also counter-intuitive. Describe the feature / enhancement and how it helps to overcome the problem or limitation: Just by adding a dedicated Documentation tab to Godot would make things clean and intuitive. You CTRL+click on the KinematicBody2D word, it sends you to the documentation about it (on the dedicated Documentation tab). And when you finished reading, you click on the Script tab to be sent back again comfortably where you were. Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: If this enhancement will not be used often, can it be worked around with a few lines of script?: I don't know how to do that. Is there a reason why this should be core and not an add-on in the asset library?: This is for Godot's improvement and success.

TheFlamyy commented 4 years ago

From my point of view, this proposals is a bit counter-intuitive. Adding a tab with similar functionality as another one makes the bar on top a bit more convoluted.

What would happen when you close all documentations with? Will it automatically switch back to the script editor or stay on an empty docs page? For example, I often close my docs tabs with Ctrl + W and thus automatically jump back to the last script.

What about having multiple categories in the script list on the left side? Instead of just having all open files, you can sort them by either file extension, type (e.g. script, other text file or documentation)

ghost commented 4 years ago

Thanks for your input.

Adding a tab with similar functionality as another one makes the bar on top a bit more convoluted.

I don't think one more little tab makes the current four-tab bar convoluted. And it would make the script tab less convoluted.

What would happen when you close all documentations with? Will it automatically switch back to the script editor or stay on an empty docs page? For example, I often close my docs tabs with Ctrl + W and thus automatically jump back to the last script.

I tried ctrl+w in the Script window, and it closes the current script, but keeps the empty tab open. I imagine they would do the same for the Documentation tab for consistency.

What about having multiple categories in the script list on the left side? Instead of just having all open files, you can sort them by either file extension, type (e.g. script, other text file or documentation)

I'm afraid you're missing the point of this whole separate Documentation tab idea, which is that the documentation shouldn't be mixed up with scripts. Scripts and Documentation are completely different things with different functions or goals. Mixing both is like putting "Settings" in "Help".

Calinou commented 4 years ago

Help used to be a dedicated tab in the Godot 1.x days, but that was eventually scrapped (I don't remember why exactly).

ghost commented 4 years ago

Well, actually I'm not that surprised: I remember watching an old Godot video, and the menus were more standard menus, like File, Edit, etc. So it seems that every time something seems illogical in Godot, it was changed for whatever reason.

As you might have gathered, I like standardization and consistency when it comes to software. ;)

Calinou commented 4 years ago

@vrbandwagon I wouldn't say so. Usability was a really common complaint in the Godot 1.x days…

I remember it, I've been using Godot actively since the 1.1 days (~May 2015).

YuriSizov commented 4 years ago

While I agree with the problem and talked about it in other issues regarding the editor UI (namely #512 and the original Reddit post), I'm not sure about the proposed solution. Another main view tab takes you out of your main context, when a "Help" section can be more helpful if you can look at it alongside the problem you are trying to solve. I can propose the bottom panel as the simplest alternative, but to be honest I'm not confident in any currently available place for the "Help" section.


What are the use cases for the "Help" section? We currently have two contextual ways to open it and a button to just pop up a search, which solves anything not covered by those two contexts.

First context is getting there from inspecting a class or its properties and methods in the Script editor. This is probably the main case for including the whole "Help" in there. And it's a straightforward case at that. It doesn't really make sense to jump you out of the Script editor to a completely different main view tab just to show some method's description. Also, don't forget that the current implementation allows users to navigate between script files and documentation rather quickly. I myself often use "Close tab" shortcut to get back from documentation to a script I was just in.

For methods and properties I'd propose doing something similar to VS Code's peek at reference:

image (Just imagine that it's help that is shown there in the blue box).

Full class reference pages still require some solution, though. The same solution that is required by a second context for the "Help" section — "Open Documentation" option in the Scene Tree dock. Maybe we can introduce a universal popup window with persistent state that you can bring up and down with a shortcut from any place in the editor? This would tie it in with the "Search Help" button in the Script Editor and the search window it creates. It would be the same window, in fact.

image

Also, keep in mind that while we only have access to the class reference in there, people constantly ask for addition of other articles and tutorials from docs, so that they can follow them or double-check them without ever leaving the editor.

ghost commented 4 years ago

@pycbouh, @Calinou, @TheFlamyy, thank you very much for your replies and input. I'm still not confident my logic was understood, but at least my post has gained some attention!

Could you please also give some love to my other posts, especially the ones about the Project Manager? Adding the option to remove a project permanently #696 and duplicate a project #969 without having to go to the OS's file manager are really important to me, and probably many users who are still at the tutorial-watching stage.

Thank you for your attention.

Calinou commented 4 years ago

@vrbandwagon Keep in mind that in open source projects, people work on what they want to work on. I'm not being paid to contribute to Godot.

willnationsdev commented 4 years ago

I similarly feel that creating an entire new main screen tab just for docs will just add a lot of unnecessary clutter since it is so closely related to script content. If you wanted to have a secondary space that is used to temporarily peruse docs content, then it may as well be made into a popup (which fits better with the multi-window Godot future anyway) - basically @pycbouh's idea. I'd still make it a configurable option in the EditorSettings though since other users may prefer to keep it in the Script tab.

And further into the future, when people can detach the ScriptEditor or even make multiple instances of the ScriptEditor, this will be a bit moot anyway since people can then easily enough just create a ScriptEditor window dedicated for storing their documentation content.

So, I'm amenable to helping OP resolve their "don't keep docs together with script files" complaint, but I don't favor the specific resolution they proposed.

KoBeWi commented 4 years ago

Also, going back from reading documentation back to your script is also counter-intuitive.

You can do this easily with these buttons: image Right now they are bound to Alt+Left/Right, but there was a proposal to make them bound to mouse X1/X2, which would probably improve the usability.