Kirigami issueshttps://invent.kde.org/frameworks/kirigami/-/issues2023-07-31T13:29:24Zhttps://invent.kde.org/frameworks/kirigami/-/issues/44KF6: NavigationTabBar enchancements2023-07-31T13:29:24Zivan tkachenkoKF6: NavigationTabBar enchancementsProposals to refactor NavigationTabBar for KF6.
1. Move delegate out of Instantiator to a top-level customizable property + inline component as a default implementation. Bing essential properties such as _preferable_ width, action and p...Proposals to refactor NavigationTabBar for KF6.
1. Move delegate out of Instantiator to a top-level customizable property + inline component as a default implementation. Bing essential properties such as _preferable_ width, action and parent in onObjectAdded hook. Use preferable with if set, fallback to normal Item::implicitWidth.
Reason: this way behavior and appearance can be altered without rolling out full NavigationTabBar override. For example, some buttons could handle long presses and show a menu, like [Dictionary Universal](https://apps.apple.com/us/app/dictionary-universal/id312088272) does on iOS for its first Search tab (it shows the list of dictionary sets, if configured in preferences).
2. Replace Row in contentItem with custom positioning code.
Reason: Allow buttons to be reordered via drag&dropped in the edit mode (which is to be done too).
3. Implement optional edit mode, exposed as a top-level bool property. Needs some model management for actions, at the very least via sort proxy.
Reason: self-descriptive.KF6https://invent.kde.org/frameworks/kirigami/-/issues/14Proposal: Convergent context menu component2021-04-09T14:57:21ZDevin LinProposal: Convergent context menu componentI would like to discuss if it is worth making some form of convergent context menu component, that can take in a series of Kirigami actions, and then provide either a regular context menu, a drawer with options, or an overlay sheet with ...I would like to discuss if it is worth making some form of convergent context menu component, that can take in a series of Kirigami actions, and then provide either a regular context menu, a drawer with options, or an overlay sheet with options depending on what the developer wants (maybe an enum).
This would be a simple list, and only be targeted at "right click/hold on item menus" specifically, if developers need anything more advanced they can create their own components.
It would also be nice to have a separator component that can be inserted between actions as well, interpreted depending on the type of context menu.
I also think it is worth extending the regular QQC2 Menu and dealing with some current headaches that people usually face:
* Opening a menu at a cursor location doesn't allow it to be closed on click (it selects the first item), so it needs a one pixel offset
* List entry highlights stays even when the mouse cursor leaves the menuhttps://invent.kde.org/frameworks/kirigami/-/issues/13Extend QQC2 controls into Kirigami2022-10-30T14:48:16ZDevin LinExtend QQC2 controls into KirigamiI think that many QQC2 components can be extended into Kirigami so that we can add functionality.
Since we are not reimplementing components, we can instead choose QQC2 components to extend instead so that it does not require as much ma...I think that many QQC2 components can be extended into Kirigami so that we can add functionality.
Since we are not reimplementing components, we can instead choose QQC2 components to extend instead so that it does not require as much maintenance.
This can provide solutions to problems like providing consistent context menus, as there is no way to provide consistent textfield context menus right now (the current solution is in qqc2-desktop-style, which causes applications that have their own context menu to show up with 2).https://invent.kde.org/frameworks/kirigami/-/issues/38DelegateRecycler should support the new model API2023-02-20T02:55:31ZJonah BrĂ¼chertDelegateRecycler should support the new model APIThe newer model API is described [here](https://www.qt.io/blog/new-qml-language-features-in-qt-5.15), under "Required Properties and Delegates".
DelegateRecycler should probably either support it, or maybe it is generally no longer need...The newer model API is described [here](https://www.qt.io/blog/new-qml-language-features-in-qt-5.15), under "Required Properties and Delegates".
DelegateRecycler should probably either support it, or maybe it is generally no longer needed.
However I still see a use case in things like Repeaters, for cases in which items are commonly added and removed.