panda3d-docs
panda3d-docs copied to clipboard
panda3d
Navigation of API Pages
Looking at the page for the NodePath class, navigation seems a little inconvenient to me:
For one, there's no contents listing to allow quick-skimming of member-names. If one already knows the name of the member in question one can, of course, just use a browser page-search to find it. However, if one doesn't, one can only scroll through the page, for potentially some distance, in order to find it.
And for another, there's no clear delineation between methods, variables, and enums. This further reduces the ease of seeking through a given page.
What I suggest, then, is this: that API pages include a contents-listing near the top, which would hold only member-names, and which would be separated by member-type (i.e. method, variable, enum, etc.). This should, I hope, allow for easier skimming and seeking in the API.
What I suggest, then, is this: that API pages include a contents-listing near the top, which would hold only member-names, and which would be separated by member-type (i.e. method, variable, enum, etc.). This should, I hope, allow for easier skimming and seeking in the API.
And to make that contents-listing even more useful, it would be great if it were sorted alphabetically instead of what seems to be a rather subjective relationship-based way, which can make it quite hard to look for a specific attribute, especially if you're not entirely sure of the exact name or meaning. And when I look at the properties of e.g. NodePath, it seems that this order isn't even applied consistently, as ancestors is nowhere near parent or children.
So, should it be completely alphabetical? Or should some things (like sub-types, enums) be hoisted towards the top/bottom?
I would suggest grouped by member-type, and completely alphabetical within those groups--so methods and functions all together, in alphabetical order; enums all together, in alphabetical order; and so on.
I would suggest grouped by member-type, and completely alphabetical within those groups
That's what I would prefer too, if possible.
As for what goes where, I'd place those things that are smaller in number above those of which there are more (on average), which should require less scrolling to the bottom to find something in particular. So from top to bottom, I would first list enums, then properties and finally methods/functions.
