Menu item width#1099
Conversation
|
It would be better if we calculate the width in the widget so that they're automatically resized. |
| /// Kind of menu item. | ||
| kind: MenuItemKind<A, L>, | ||
| /// Optional width override for this item's submenu. | ||
| width: Option<u16>, |
There was a problem hiding this comment.
A min and max width might be better as the widget should be calculating width automatically. The width will change depending on the language use.
|
This should also update the menu examples, and have examples included in the code docs |
|
Might also be nice if there was a context menu widget that has the same behavior as the menu bar popups, so that it can have nested menus (e.g. Open with... > list of apps in a nested menu in COSMIC Files). Or maybe the same widget and it just differs in the way it's spawned? |
I can definitely update the examples and code docs. |
|
@mmstick, I've updated the examples and doc comments. I also added min_width and max_width builder options, updated |
b50aab2 to
7903ee1
Compare
Summary
Refactors
MenuItemfrom an enum to a struct wrapper, adding a.width()builder method that can be applied to any menu item type. This lets applications control submenu widths without hardcoding values into libcosmic forks/patches.Problem
Currently, there's no way to set a custom width on menu items. This causes issues when menu content (like file paths) is longer than the default width, resulting is bad looking UI.
Before:

After:

Changes
MenuItemenum toMenuItemKindMenuItemstruct wrappingMenuItemKindwith optionalwidthfield.width(u16)builder methodbutton(),button_disabled(),checkbox(),folder(), anddivider()menu_items()to apply width to all item types.responsive_menu_bar.rsto use new APIUsage
Migration
Existing code using enum variants (Item::Button(...), Item::Folder(...), etc.) should switch to the method constructors (Item::button(...), Item::folder(...), etc.). The From impl provides backwards compatibility for code that builds MenuItemKind directly.