Bug 404978 - Make drawer & action items more composable to support custom UI patterns
Summary: Make drawer & action items more composable to support custom UI patterns
Status: REPORTED
Alias: None
Product: frameworks-kirigami
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: Not decided
Assignee: Marco Martin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-02 07:10 UTC by Eike Hein
Modified: 2019-03-04 14:47 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.