Config #2
Description
Right now we create actions like so:
We can probably make this experience much smoother.
Some requirements to keep in mind with this experience:
We can create multiple actions. We'll change the KBarProvider to accept initial_actions but we can also dynamically create actions using some function like add_actions(Vec<Arc<KBarAction>>).
We'll need to change the internal actions state to a tree that mimics the routing of different actions.
A visual thinking:
Global actions: [Home, Documentation, Settings]
inside documentation: the subactions could be ["source code", "help desk"]
inside settings the subactions could be ["edit profile", "change theme"]
This will also mean that a KBarAction needs another attribute that holds the reference of their parent kbaraction (Option since global/root action parents are None)