Use KDropdownMenu to render content nodes menus

[AlexVelezLl]

Summary

Description of the change(s) you made

Replaces VListTile, VMenu, and ContextMenuCloack with KDropdownMenu to show content nodes menus

Manual verification steps performed

1. Checked the following content node menus:

• The menus of the items of the main list
• The menus of the folders tree view
• The menu that appears when clicking the dropdown icon in the bradcrumbs row
• The menu that appears on the resource details

2. Checked the following context menus:

• Right clicked on the items of the main list
• Right clicked on the items of the folders tree view

Screenshots (if applicable)

Compartir.pantalla.-.2024-03-25.15_52_05.mp4

---

Reviewer guidance

How can a reviewer test these changes?

1. Go and edit a channel
2. Check the menus and context menus listed above.

References

Closes #4403

Comments

This should be merged after KDS is released with learningequality/kolibri-design-system#583 merged.

Also, after replacing KDropdownMenu on the content node menus, there will be some issues on keyboard navigation that will be fixed when learningequality/kolibri-design-system#588 is fixed.

---

Contributor's Checklist

PR process:

• If this is an important user-facing change, PR or related issue the CHANGELOG label been added to this PR. Note: items with this label will be added to the CHANGELOG at a later time
• If this includes an internal dependency change, a link to the diff is provided
• The docs label has been added if this introduces a change that needs to be updated in the user docs?
• If any Python requirements have changed, the updated requirements.txt files also included in this PR
• Opportunities for using Google Analytics here are noted
• Migrations are safe for a large db

Studio-specifc:

• All user-facing strings are translated properly
• The notranslate class been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. icons, user-generated text)
• All UI components are LTR and RTL compliant
• Views are organized into pages, components, and layouts directories as described in the docs
• Users' storage used is recalculated properly on any changes to main tree files
• If there new ways this uses user data that needs to be factored into our Privacy Policy, it has been noted.

Testing:

• Code is clean and well-commented
• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Any new interactions have been added to the QA Sheet
• Critical and brittle code paths are covered by unit tests

---

Reviewer's Checklist

This section is for reviewers to fill out.

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[AlexVelezLl]

All these difs are just tab diffs since we are removing the and tags.

[AlexVelezLl]

Idem, just tab diffs, the relevant changes starts in line 129

[marcellamaki]

Hi @AlexVelezLl - overall I think a first pass-code read through looks good. When doing a little bit of manual QA, one problem I encountered was scrolling within the menu. I'm not totally sure what the expected behavior should be, actually, but when the open context menu opens and flows past the bottom of the viewport, I can't seem to scroll within it to see the bottom items.

This is probably (?) something to fix in KDS rather than here, and maybe requires some decision making of what the ideal behavior would be.

My only semi-considered opinion is that having a max height and scrolling might be better than having a very, very long menu. (i.e. a menu of the full screen height on a browser seems overwhelming). And maybe we could have a mobile interaction as well.

sorry that I did not consider this in the KDS review!

other than that I think things here look quite good and we can move forward with the feature into unstable once we get this sorted (and once we have the descendent behavior conversation)

[AlexVelezLl]

Hi @marcellamaki, thank you!! And yes, previously I had added an 80vh max-height, it was an empirical value, and I was basing it on a fixed vh value since it does not matter if the dropdown opens downwards or upwards, since tippy knows how to position it appropriately so that it fits on the screen. But I think we can open a follow up issue for it in KDS and have a consensus on how to calculate this max-height.

I think this could be included in a new v4 version of KDS, since we had planned not to make any more releases in v3 (which is the current version of KDS in the studio-usability-enhancements branch until the rebrand work is merged to unstable) , so we would have to wait a bit until we see this change in the studio-usability-enhancements branch.

What do you think about it?