Hi @Tom_P, yes. Your suggestion and the change @mkarimi made afterwards has been already a big improvement in readability. Iāve seen that the paramter types (links) are beeing worked on now while re-reading the whole tread. This is great. The (missing link) color is only bad when in darkmode for me.
Another slight thing for the right column when the namespace is displayed. In the old system this was a 2 column table and each row had a dimish gray line to seperate the table items:
Thank you both @clement and @Tom_P for your detailed comparison and pointing out what works and what doesnāt. And thank you @Gijs for making YTs.
Some of the things you brought up are bugs that Iām going to fix as soon as possible. Like:
and
I also agree with most of your styling suggestions for the right panel. We need to improve readability of that section.
Regarding the tree, I think we can make some styling improvements to make it more readable but I want to keep it as a global navigation tool. I think part of the reason the old tree looked cleaner was because it omits all other members of a class (which was a limitation of SandCastle), I donāt want to go there.
The new site also has 1-1 correspondence between member urls and nodes in the tree, and weāre using the name of the member (without the argument) as the url slug. Thatās why the three flavors of CreatePatch get grouped together. Iām hoping to solve the issues you have with these kind of grouped methods with styling as the alternative would require changing the urls to something less readable.
This is a known issue, right now we donāt have a way of extracting urls for external types. Iāll do some research on that.
Hi @mkarimi, yes. It reduced the number of tree items by adding a another (single) item per class and multiple members as child elements. I think itās not an easy decision what is better. If you keep displaying the arguments for each member the tree is way to wide. If you remove them, youāll get the same member name and it might look like duplicates. At least for me, it appears that, with an increasing amount of tree items in the future, it might make sense to āgroupā members by adding extra tree items and subitems per member. In any case i would remove the class member arguments from the tree items. For some of the items in the methods, the arguments are wider than the monitor. I see that sandcastle added line breaks and displays them in the tree too if they are part of a group. Imho, the arguments are shown in the right column anyway so there is no need for duplication.
@mkarimi While you are improving the documentation, can you please add a large disclaimer to the old documentation, that it is not up to date any more. If you search in Google it still appears as the top result and nothing on the page suggests that it is outdated. It took me quite a while to figure out what was happening and why it was not working as expected until I noticed the documentation hasnāt been updated since 2017.
You can add a robot.txt file to the old documentation to discourage search engines.
here is what it links to, which is not up to date: InsertBlock
Of course even better would be to create 301 permanent redirects from the old URLs to the equivalent URLs in the new documentation, since that will cause Google to update its result, without loosing the ranking. So in the case of the search above it would use the new URL as the top result. It might be a bit of work, but maybe there is some way to automate the mapping from old to new URLs.
Thanks!
ps: I am aware this is for RhinoScript and not RhinoCommon, but its very much related and I assume you might be in charge of both.
Iām only updating the RhinoCommon documentation at the moment. RhinoScript documentation is a separate project that as far as I know weāre not updating.
another potential to improve i found today:
it would be great if the click on the tree for multiple definitions / signatures of a function/ constructor also scrolls to the section ā¦
The links to InsertBlock help are for two different APIs. That is, RhinoScript (VBScript) is not the same as rhinoscriptsyntax (Python).
The rhinoscriptsyntax API is a set RhinoScript-like function, written in Python using RhinoCommon, that were intended to help those migrating from legacy VBScript.
And rhinoscriptsyntax is open source. Here is the code:
Thanks @dale I didnāt realize that at all! Thanks for the clarification! Maybe the old docs could get some kind of header and footer where this could be clarified.
I think itās also a UX issue with the search on Rhino Developer. When you are on the main page for Rhinoscriptsyntax Rhino - Rhino.Python Guides and see the search bar I think itās fair to assume that you are searching in the Rhinoscriptsyntax. But if you search for āInsertBlockā there you get what look like Google Search results and the top result is for the Rhinoscript page for InsertBlock. On that page nothing suggests that you are now in a totally different āRhinoscriptā. Since the syntax for InsertBlock is basically identical for VBScript and Python you also donāt even think that it might relate to something very different.
It would be nice to have a proper search box where you search only in the current Script language.
I believe having clearer search results and better search options would really help in this regard.
There is another more general idea in my mind regarding documentation:
I think it would be super nice / helpful to have a place where the different Development Environments link the same functionality.
this would somehow answer all those āwhat s the ā¦ equivalent of ā¦ā and would allow easy starting points for new developers or those you switch from one world to the otherā¦
ā¦ ok i know it s a lot of workā¦
It is not super important for me, but when starting programming in Rhino, I often had this kind of question.
