cogentcore.org/core categories navigation menu on the left is no longer displayed in docs #1472
Comments
|
I should add that I do get a navigation menu on the left if i right click -> inspect
|
yeah, it would be helpful, but context menu -> About could be used at the moment. |
it doesn't actually show the version for me. It just shows the app version as
|
|
@0pcom yes, you are right, it works for root path. |
|
@0pcom i have no idea how it was designed initially, but you should click on either "Get started" or "Install" buttons to make the menu be shown. |
|
@AnyCPU I see now
However, I know that the docs is it's own separate app. The version could be different for that than for https://www.cogentcore.org/ ... More feedback on the current issue I've been able to navigate the docs via the address bar (useful!) to view some pages. At one point it crashed
It looks alright besides the sidebar nav menu not having the full navigation
So I attempted to run the docs locally. I reinstalled For the above error... really it's recommended to include the vendor dir here in this repo but I recall @rcoreilly said it messed up his IDE to do that. Just a note. Continuing:
slightly humorous static preview, but it got stuck there. When I refreshed the page again:
sidebar nav is still missing. But the errors make it more clear as to why exactly that may be. |
Before, if you went to https://www.cogentcore.org/core/ to the left of At least, that's how it was before. If it's not supposed to be there on that page any longer, then why is there still space reserved for it? The navigation menu is supposed to be there, I'm fairly certain. There is no good way to navigate the docs and most pages which exist don't have a link to them, so you can't really navigate to them outside of knowing exactly what to put in the address bar. |
|
@kkoreilly i hope following will be helpful macOS + Firefox macOS + Chrome macOS + Safari Env: |
|
some api might be disabled in case of the brave browser. |
it worked fine before the new docs website was deployed |
|
@0pcom Thank you for filing this issue. We really appreciate your feedback. The original decision was to intentionally reduce the scope of the left navigation menu, with the expectation that the search button in the toolbar, the new wikilinks, and the new contextual navigation menu on the left would be enough, in a system more similar to Wikipedia/MediaWiki (once you click on "Get started", you can follow the wikilinks almost everywhere). However, we were aware that the navigability was impacted, and we were planning to add more navigation options to the toolbar and the left panel. Given your feedback, it is clear that we need to do more. Apologies for this unclear decision and the reduced navigability it caused. It may seem like we should just go back to putting all of the pages on the left panel, but the reason why we shifted to this new system is that the number of pages is increasing and will continue to do so as we add more documentation, and so having a giant tree with eventually hundreds of pages that you have to scroll through might not be as useful. Also, we made a shift to a flat structure with many-to-many categories, as we often found that it was hard to remember exactly what directory a certain page was in, reducing its discoverability. The current left panel displays all of the pages in the same category as the current page, and all of the headings on the current page. However, that only provides navigation within a category, so one idea would be to also display all of the categories on the left, which you could then click on to find links to all of the pages in that category. We could also include all of the pages directly in that tree, but just have them collapsed by default underneath the categories. We could also add a separate index/sitemap page on which you can see the list of all pages. The other consideration is that search is supposed to be a powerful tool for easily finding pages without scrolling through a big list, but it seems like the discoverability of the search button might not be very clear. We could consider making it more of a clear search box, or we could at least add text to the button. We are also planning to support searching for things like headings, which would also increase the chance of finding what you want. Regardless, we would greatly appreciate your feedback on how you think it should be structured. Apologies for the confusion. |
|
@0pcom @AnyCPU Regarding WebGPU, that error message does indicate that it is falling back to the backup 2D drawer, and we could indicate that directly in the log, or just remove the message entirely; what do you think? For the version information, we are aware of that issue with the about dialog and will work on fixing it. We will also try adding it directly to the website. @0pcom I don't know why the static preview is like that; that typically indicates that the |
|
I vote for adding all of the categories at the bottom of the nav tree. Maybe add the word "Search" next to the search icon? |
@kkoreilly it would be nice to cover that code by using tracing options that we can see in the core's settings dialog. there is no need in an error msg if we have fallback option. |
|
@kkoreilly a one of good practices i've seen in Go is:
i will prepare a pr with example |
|
@kkoreilly an example 618544a |
|
@0pcom could you reproduce the app crash? |
I was only confused because it seemed like the links should be there on the left because space was reserved there for something. It's just empty space without that, on desktop. Perhaps it looks better on mobile. For optimal performance, I think the approach you chose was best in that it limits the amount of stuff being rendered on any given page. Or at least on the front page of the documentation. I understand why this is actually necessary and a good idea - because any animation will suffer when there is too much on any one page. If you were going to include something animated. I would like to see a list of at least top level categories somewhere. I am actually fond of that tree with collapsible branches, that's something which people might want to use. But it is demonstrated on subsequent pages, so it's not as though it's excluded by the recent changes. My only real issue is that... when I get to the end of the page of a certain category, it should somehow link to the next logical page or category Here at the bottom of the page, several links are presented: On following these links, not every subsequent page has a link at the bottom to the 'next page' or 'next section' or 'next category' - nor is it always apparent what the next page is. They all have links on them, it's just confusing to know where you are at with it or where you want to go next or how much is left that you have not seen.. So, I really actually do like the categories menu because it enables somewhat lazy browsing, and you don't need to know what you are looking for to find it. But in lieu of that... If I think of a presentation based on the documentation, it should basically flow through every available page. In another sense, if the site was crawled, basically every link would be visited. And the documentation would sortof flow linearly to the next most logical section or category, through all the subheadings, and then to the next category and so on. And then the last page either links back to the beginning or doesn't link anywhere, but tells you that you reached the end of the documentation. The design layout of the documentation is really up to you guys. But if you want my two cents on it:
then, people can see how that page with the massive tree performs, if they wanted to do something similar, and it also becomes easier to browse categories and subcategories out of order. Another thing... don't be afraid of redundancy. To the extent that is optimal and does not bloat the resulting binary. Redundancy is your friend. If there are multiple ways to explore the documentation, that's not a bad thing. Perhaps it might seem messy, but variations of examples are not a bad thing. It just gives more places where the user can start by directly copying something into their own code. As good as the documentation is, and while the software / user interface should really speak for itself ; if you made a video of going through the documentation, talking about it, interacting with it, and if you at least hit all the major points / categories that you want to cover, and then mention the things that you aren't directly talking about and show people where they can read more about it, I think that would be a thoroughly enjoyable thing to watch. Especially with your narration & insights. However, I know that you might be loathe to do that and then need to re-do it if you changed something in such a way that the video no longer reflected the documentation. It's just a suggestion. What you are doing, specifically with the documentation, presents a unique challenge of communication. And I think it's been handled with impressive clarity, considering the level of complexity this entails. ... Another thing to mention, an oddity. If I go here:
If I click https://www.cogentcore.org/core/app Now |
I can produce them sometimes but reproducing them is more difficult. I'll be certain to make an issue ticket here if I encounter any more crashes. |
0pcom
changed the title
|
Will the docs site be changed anytime soon, or is it otherwise possible to see all the categories somewhere so that I can examine the updated documentation in it's entirety via category navigation? Also, the canvas animation example included in the docs which appears smoothly when run as a standalone example but in the documentation it suffers from brief stutters or hiccups cogent-core-canvas-animation-2025-02-13_10.16.53.mp4When I remove the code for the canvas animation and substitute the following code: it severely affects performance, making scroll & the page itself slow to respond. increasing width and height decreases page responsiveness. |
|
@0pcom as i can see some work is being done for new painting/rendering. i have some ideas why it may happen in your case, but i guess it is ok to wait for a new impl at the moment. |
|
@0pcom As @AnyCPU mentioned, we are currently working on a major redesign of the rendering infrastructure (#1457), especially on web, which should greatly improve performance of these kinds of things. We are planning to update the website soon; we haven't had the chance to fully discuss the situation and implement a good solution yet, but we should be able to do that within the next week. We appreciate your feedback, and I will definitely get back to you soon. In the meantime, if you click on the search button and then on the little arrow on the right of the text field in the search dialog, you can scroll through a list of all of the pages. Thank you for your patience and please let me know if you have any other questions. |
Exciting to hear, I'm looking out for updates!
That will suffice for browsing / lazy navigation. I must have missed that. Overall this CORE framework is progressing nicely! This is one of the best projects to follow in 2025. |
Describe the bug
First noted here:
#1447
Before I begin, I just want to suggest that it might be super helpful to display the actual version / revision / commit on the documentation here: https://www.cogentcore.org/core/
If it's displayed where it can be captured in a screenshot ; or even if you include it in... the title attribute, here, below the text that says
Homethen I can be sure it makes it into a screenshot:Or even at the end of that top menu bar after sponsor, roughly where the mouse is in this image:
Then it should be easier to know what commit was used or that it was the updated / most recent version of the site.
...
Assuming that I am looking at the latest version and there isn't some weird caching situation going on, the issue is as follows:
This is with brave browser on (arch)linux:
F12to open the browser console (in brave), and nothing happens.That's typically a sign that something has gone wrong. But it may be a behavior I've noticed before when there were no errors with the display.
F12while the static preview is there, before the wasm loadsThis is displayed in brave:
This is displayed in waterfox:
Shouldn't there be a fallback to non-webgpu if webgpu isn't supported? Or did it just fall back without logging?
Originally posted by @0pcom in #1447 (comment)
How to reproduce
Look at the updated documentation website on linux (using either brave browser or waterfox)
https://www.cogentcore.org/core/
Example code
Relevant output
Platform
Linux
The text was updated successfully, but these errors were encountered: