Create docs button for FileSystem resources

[thiagoamendola]

Like the node's context menu from the Scene tab, the context menu for
resources in the FileSystem tab should contain an "Open Documentation" button.

The "Open Documentation" button for resources can open the documentation for
given resource's type. It works with multiple file selections and avoids
opening an empty documentation tab for folders.

[aaronfranke]

@thiagoamendola Is this still desired? If so, it needs to be rebased on the latest master branch. While there are no conflicts, rebasing is important so that reviewers can easily test the PR.

[thiagoamendola]

Thanks for the ping. Just rebased the branch.

[groud]

I think the feature might be desired, but I see two problems with the implementation:

• Whatever the file we have, the option is displayed anyway. I am pretty sure some files aren't going to have an associated documentation page. So it would be better if the option is only displayed when a documentations associated to the file type exists.
• What happen to files that can be imported as different types (like, where you can choose the type in the import panel) ?

[thiagoamendola]

@groud about those 2 issues:

• Does it make sense to quickly load the documentation page and check if it's empty? I'm worried about adding an overhead time in the popup opening step. Another options could be to either cache available extension pages or show a different default page in case there's none available.
• I think it'd be okay to process a file with its current chosen type. Do you see any cases where this can be a problem?

[groud]

I had a look to the code. Apparently there is no checks done for the documentation page to exist anywhere else in the code. So I think keeping it like that is ok. Custom types without a documentation will likely trigger an error and do nothing, but I am not sure.

I think it'd be okay to process a file with its current chosen type

I think it should be enough, but I think we should mention the class name in the text line then. Something like "Open documentation for <class name>".

[thiagoamendola]

By testing the button on a file type with no available documentation, the following empty page is displayed:

It doesn't break but it doesn't tell much either. Do you think it's ok showing it?

Also, about the "Open documentation for " suggestion, won't the option string become too big, making the popup cluttered?

[groud]

I am not sure, I think it would be better to have something implemented to avoid this, as we're going to have issue report about this. I guess we should summon @akien-mga here to give us his opinion.

[akien-mga]

By testing the button on a file type with no available documentation, the following empty page is displayed:

Yeah that would need to be prevented. The code should only query opening the docs if it's a file type that matches a builtin Node.

Also, about the "Open documentation for " suggestion, won't the option string become too big, making the popup cluttered?

Yeah that's a bit too verbose I think. Some translations might make it even worse.
Could be "Open Class Documentation" only without putting the specific class name. And the code you have to figure out the class name can likely be used to solve the first point above, so that the menu entry is not shown when there's no class name. Beware of user-defined classes which may not have documentation either though (but I think ClassDB or DocData might have relevant methods to let you figure out what's builtin/documented and what isn't).

[akien-mga]

Would be good to get this re-reviewed / tested, @godotengine/docks.

I think it's fine to add this kind of option but we should make sure it also works e.g. for going to the generated documentation for GDScript classes.

[KoBeWi]

I tested with scripts and it opens GDScript resource documentation instead of the custom class documentation. Seems to work fine in other cases.

So this needs a rebase and fixing the GDScript issue.

[MewPurPur]

Are you still around to rebase?