Bug 404978

Summary: Make drawer & action items more composable to support custom UI patterns
Product: [Frameworks and Libraries] frameworks-kirigami Reporter: Eike Hein <hein>
Component: generalAssignee: Marco Martin <notmart>
Status: REPORTED ---    
Severity: wishlist    
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: Not decided   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Eike Hein 2019-03-02 07:10:15 UTC 
In my application, I would like to realize the following architecture:

* Use an AbstractApplicationWindow, as ApplicationWindow packs too much UI and features I don't use or want/need.
* Use an OverlayDrawer, as ContexDrawer doesn't work with AbstractApplicationWindow and has UI I don't want or need (e.g. a heading above the actions) and is also used in a way I don't like (I can have an OverlayDrawer in a page and therefore lazy-load it, while a ContextDrawer must be assigned to an (Abstract)ApplicationWindow prop and is therefore global).
* Inside the OverlayDrawer, I'd like to present a combination of custom UI and a hierarchical action menu much like ContextDrawer can do.

In trying to do this, I face the following challenges:

* The delegate item used by drawers concert with Kirigami.Action is not public API.
* The listview item used to hold action delegates and its behavior is not public API.


I'd like to see changes to make all of this more composable and flexible, e.g.:

* Make ContextDrawer more flexible to use, lifting the limitations mentioned above.
* Make action list views and action delegate items public API, so they're usable in custom OverlayDrawer host items.
Comment 1 Marco Martin 2019-03-04 14:18:11 UTC 
I'm inclined to mark this bug invalid for some reasons:
* It speaks about several things, it's not one issue per report
* ContextDrawer is supposed to work anywhere: it can work completely automatically only on applicationwindow, but it has a list action property which can be assigned to whatever (on abstractapplicationwindow is the applications responsibility to bind the actions: property to the proper values
* I'm resistent about making those delegates a public type: they never were made to have good public api and make sense only in the drawer 

the thing that i think is valid and i think 06af8aac8 adresses, is the ability to put custom content:
now header and footer properties are exported that let inserting arbitrary stuff over and under the actions (setting an header also removes the title item as isn't instantiated anymore).
Comment 2 Eike Hein 2019-03-04 14:47:47 UTC 
Sounds good, go ahead.