Kirigami issueshttps://invent.kde.org/frameworks/kirigami/-/issues2023-07-01T16:17:33Zhttps://invent.kde.org/frameworks/kirigami/-/issues/58Update Material 32023-07-01T16:17:33Zivan tkachenkoUpdate Material 3The Material 3 update in QcQtuickControls removed lots of stuff, which breaks our bundled Kirigami/Material/Theme.qml in lots of interesting ways. It needs to be updated.
Turns out, most of those properties were not even documented, thu...The Material 3 update in QcQtuickControls removed lots of stuff, which breaks our bundled Kirigami/Material/Theme.qml in lots of interesting ways. It needs to be updated.
Turns out, most of those properties were not even documented, thus they were considered private, and were allowed to break between minor releases. Interestingly, Material implementation of controls uses that "private" API quite a lot, including a very useful function:
```qml
color: control.Material.buttonColor(control.Material.theme, control.Material.background,
control.Material.accent, control.enabled, control.flat, control.highlighted, control.checked)
```
…which handles most of the conditional logic in fast C++ code.
https://invent.kde.org/qt/qt/qtdeclarative/-/commit/f47f8d69319fa7b0b71cc8036c5bdfd1e8407e70ivan tkachenkoivan tkachenkohttps://invent.kde.org/frameworks/kirigami/-/issues/32Undeprecate Units::fontMetrics2023-02-15T12:39:49ZNoah DavisUndeprecate Units::fontMetricsCreating an object in C++ via embedded QML is clearly undesirable, but the properties and functions made available via Units::fontMetrics are desirable. It's an efficient way to get any information you might want to know about the defaul...Creating an object in C++ via embedded QML is clearly undesirable, but the properties and functions made available via Units::fontMetrics are desirable. It's an efficient way to get any information you might want to know about the default font. Without it, if I wanted to use the descent or x-height of the default font in a reusable component, every instance of it would have to have its own FontMetrics object. Perhaps we could create a private C++ class that does the same things as QQuickFontMetrics? All it needs to do is expose what QFontMetricsF has to QML.https://invent.kde.org/frameworks/kirigami/-/issues/52SwipeListItem seems to be broken with QT_QUICK_CONTROLS_MOBILE=12023-06-21T23:47:16Zivan tkachenkoSwipeListItem seems to be broken with QT_QUICK_CONTROLS_MOBILE=1SwipeListItem's swipeable content disappears after swiping+clicking. Only reproducible with `QT_QUICK_CONTROLS_MOBILE=1`, because without mobile controls I don't get to swipe with a mouse. It doesn't even seems to be possible to click th...SwipeListItem's swipeable content disappears after swiping+clicking. Only reproducible with `QT_QUICK_CONTROLS_MOBILE=1`, because without mobile controls I don't get to swipe with a mouse. It doesn't even seems to be possible to click those action buttons underneath the swipeable area.
Can be reproduced on tests/swipeListItemTest.qml file.
It was not so broken in kf5, although it was also possible to "get rid" of the content item temporarily (until next click).KF6https://invent.kde.org/frameworks/kirigami/-/issues/42Style Selector and declarative type registration2023-09-25T09:51:54ZNicolas FellaStyle Selector and declarative type registrationin kirigamiplugin.cpp we use qmlRegisterType to register QML files. We do this to select different QML files based on the selected style.
This is, somewhat fundamentally, incompatible with the new declarative type registration where thi...in kirigamiplugin.cpp we use qmlRegisterType to register QML files. We do this to select different QML files based on the selected style.
This is, somewhat fundamentally, incompatible with the new declarative type registration where things must be known at compile-time. Pretty much all new stuff in QML (scriptcompiler/typecompiler, tooling stuff, LSP etc) is based on that. Not being able to use declarative type registration would therefore probably be a huge hurdle moving forward with adopting modern QML practices.https://invent.kde.org/frameworks/kirigami/-/issues/60Splitting Kirigami into Submodules2023-09-11T13:58:01ZArjen HiemstraSplitting Kirigami into SubmodulesOne thing that we ran into during the Frameworks 5 lifetime is that it is hard to define what should and should not be in Kirigami. This lead to some things being included that maybe should not have been. However, to do that in the curre...One thing that we ran into during the Frameworks 5 lifetime is that it is hard to define what should and should not be in Kirigami. This lead to some things being included that maybe should not have been. However, to do that in the current situation, we would need to define "What is Kirigami" for all of Kirigami, which is hard. So rather than trying to define that, I had the idea a while ago that it might be better to split Kirigami up into smaller submodules, with each submodule having a clear defined purpose. This would allow us to more clearly say "this belongs here" or the opposite. Additionally, it makes it easier for developers to pick and choose what they need and hopefully also reduces the dependencies between different parts of the code.
We discussed this during the Kirigami BoF at Akademy 2023 and generally agreed that it would be a good plan. We also discussed in what way we wanted to split things and this is so far what we came up with:
<dl>
<dt>Primitives</dt>
<dd>Primitive Items, that is, things that only inherit QtQuick Item or even QtObject, are not opinionated and generally just provide some sort of basic thing. Generally don't provide their own styling. Only depends on QtQuick.
Things planned to be included: ShadowedRectangle and friends, Icon, Separator, ListItemDragHandle.
</dd>
<dt>Controls</dt>
<dd>Single controls that inherit `Control` or `AbstractButton`. Mostly unopinionated, provide default styling but can be restyled using the usual Controls customisation process. If there's no existing QtQuick Controls template that can be used a template should be provided in the separate "Templates" module. Should only depend on QtQuick.Controls and things from the Primitives module.
Things planned to be included: Card, Chip, Action, ActionTextField and derived controls, Link/UrlButton, PlaceholderMessage and LoadingPlaceholder, ListSectionHeader, SwipeListItem.
</dd>
<dt>Layouts</dt>
<dd>Non-visual items that are dealing with placement of items. Unopinionated, should provide customisation points for anything opinionated that needs to be done. Should only depend on QtQuick.Layouts and things from the Primitives module.
Things planned to be included: FormLayout, ToolBarLayout, PageRow(?)
</dd>
<dt>
<dt>Dialogs</dt>
<dd>Visual items that pop up over existing contents. Fairly opinionated, as these mostly implement behaviour specific to KDE software. Should mainly depend on QtQuick.Controls and the Primitives module.
Things planned to be included: Dialog, MenuDialog, PromptDialog, OverlaySheet.
</dd>
<dt>Platform</dt>
<dd>Platform integration facilities and types that are used to get information from the platform. Should not contain any visual items. This includes a library to provide platform-specific implementations of some of these types, what used to be "libkirigami".
Things planned to be included: Theme, Units, InputMethod, VirtualKeyboard, TabletMode
</dd>
<dt>Framework</dt>
<dd>Higher level components that are meant as an application building framework. Will often include types that combine a bunch of controls in certain ways. Very opinionated, it basically defines the "Kirigami" application style. Can depend on anything else in the Kirigami module.
Things planned to be included: ApplicationWindow, ActionToolBar, Drawer subtypes, InlineMessage, Page types
</dd>
<dt>Templates</dt>
<dd>Behaviour-only implementations of various controls that are meant to be overridden by styles.</dd>
</dl>
This won't magically solve all our issues with "what goes where" but should at least make it simpler to determine if a certain thing should be included, especially with some simple rules about what things are allowed to depend on. Other than that, we should probably come up with a rule like "should be used by at least three applications before being included".
One thing I didn't discuss but which I would also like to propose (and I saw others already do the same) is to add some kind of "labs" module, as a place for API to mature. We have seen several things in Kirigami be either completely thrown out because the API doesn't work properly or things that are awkward to use. Having some place where we can say "this API may still change, but please try this thing" would be very useful for things to be included faster. I do suggest we come up with some kind of rule like "a final decision needs to be made 6 months after the first release with it included" or so, to prevent the labs module from turning into yet-another dumping ground.https://invent.kde.org/frameworks/kirigami/-/issues/10Should we use a bottom toolbar instead of floating action buttons by default ...2021-02-18T14:44:36ZNoah DavisShould we use a bottom toolbar instead of floating action buttons by default for mobile?We've talked about it in the VDG and Kirigami chat rooms a few times already and some of us have expressed support for the idea. It's time to have that discussion in a more permanent place.
cc: @teams/vdg @martWe've talked about it in the VDG and Kirigami chat rooms a few times already and some of us have expressed support for the idea. It's time to have that discussion in a more permanent place.
cc: @teams/vdg @marthttps://invent.kde.org/frameworks/kirigami/-/issues/15RFC: Configurable shortcut actions2021-07-17T09:40:14ZCarl Schwancarl@carlschwan.euRFC: Configurable shortcut actionsIn KXmlgui applications it is possible for the users to update the shortcuts used to trigger some actions. This is very useful. The problem to implement something like this in Kirigami, we would need to add a KConfig dependency to store ...In KXmlgui applications it is possible for the users to update the shortcuts used to trigger some actions. This is very useful. The problem to implement something like this in Kirigami, we would need to add a KConfig dependency to store the shortcuts. A possible solution would be to implement this feature in a new library and extends Kirigami.Action to make it possible to register the shortcuts and list of the managed actions. This would also mean that every kirigami application that wants to use this feature would need to replace all their Kirigami.Action with NewFramework.ManagedAction.
This is impractical for the developer and would mean that the behavior of the buttons isn't consistent across all the kirigami applications and inside the application themselves since it can happen that an application only use the ManegedAction element for only a few actions and not all.
An alternative solution (and in my opinion a better one) would be to add partial support to `Kirigami.Action` for the feature and only try to manage the actions shortcuts if an ActionManager has been registered in `Kirigami.ApplicationWindow`. That would reduce the number of changes required for an existing application to use this feature. The ActionManager interface could be defined in Kirigami and the actual implementation could live in Kirigami-addons or a new library. We will probably need to make sure that all the KDE kirigami applications use it for behavior consistency, but third-party applications can decide to not use this feature.https://invent.kde.org/frameworks/kirigami/-/issues/49Revise LinkButton & UrlButton signals API2023-09-18T10:24:19Zivan tkachenkoRevise LinkButton & UrlButton signals APICurrent signalling API of LinkButton consists of
```qml
signal pressed(var mouse)
signal clicked(var mouse)
```
but they are being abused in the very same component by `Keys.onPressed` and `Accessible.onPressAction` to pass fak...Current signalling API of LinkButton consists of
```qml
signal pressed(var mouse)
signal clicked(var mouse)
```
but they are being abused in the very same component by `Keys.onPressed` and `Accessible.onPressAction` to pass fake event objects.
Moreover, as demonstrated by the UrlButton subtype, API consumers are only ever interested in right mouse button on press (to open context menu), and left mouse button on click:
```
onPressed: mouse => {
if (mouse.button === Qt.RightButton) {
menu.popup();
}
}
onClicked: mouse => {
if (mouse.button !== Qt.RightButton) {
Qt.openUrlExternally(url);
}
}
```
_there are not so many choices with `!== Qt.RightButton` and `acceptedButtons: Qt.LeftButton | Qt.RightButton`_
**The proposal** is to redo signals with different names that would provide more restricted but targeted API.
How about this?
```qml
signal contextMenuRequested(/*nullable*/ position)
```
and then wrapping QtQuick/Text and adding `<a>` tag to it, so that it becomes a real link, and emits `Text::linkActivated(string link)` signal on its own?
Either way, wrapping or not, this component should be at least reusing `linkHovered` & `linkActivated` signal for compatibility and convenience.KF6ivan tkachenkoivan tkachenkohttps://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/8Overwrite the defaultFont property of the PlatformTheme2020-12-27T17:07:15ZCarl Schwancarl@carlschwan.euOverwrite the defaultFont property of the PlatformThemeI would like to allow users to modify the font size of the timeline, unfortunately the defaultFont property is not writable and the following code:
```qml
Kirigami.Theme.defaultFont.pointSize: baseFontSize * Settings.fontSize
```
creat...I would like to allow users to modify the font size of the timeline, unfortunately the defaultFont property is not writable and the following code:
```qml
Kirigami.Theme.defaultFont.pointSize: baseFontSize * Settings.fontSize
```
create the following error:
```qml
qrc:/imports/NeoChat/Page/RoomPage.qml:107:24: Invalid property assignment: "defaultFont" is a read-only property
```https://invent.kde.org/frameworks/kirigami/-/issues/3New Kirigami Logo/Monogram2023-09-28T13:11:48ZAndy BettsNew Kirigami Logo/MonogramThe current monogram used by our Kirigami website and other components is in need of design. I worked on a new monogram that we could use. I believe it is stronger and it strikes the view a little better. There are good monochrome versio...The current monogram used by our Kirigami website and other components is in need of design. I worked on a new monogram that we could use. I believe it is stronger and it strikes the view a little better. There are good monochrome versions of this monogram that can also be adapted pretty well. Here you go. Thoughts welcome.
@teams/vdg
![Kirigami_Icon_2](/uploads/0383433d0816493bc48f4a81075bb0e4/Kirigami_Icon_2.png)
Monochrome version
![Icon-Original](/uploads/e8ae6d23b35666884a357256c96974a9/Icon-Original.png)Andy BettsAndy Bettshttps://invent.kde.org/frameworks/kirigami/-/issues/64More API changes that must happen before 6.02023-10-22T09:30:55ZMarco MartinMore API changes that must happen before 6.0There is still some API to remove, therefore it needs to happen before freeze, proposals are:
# Cards
- [ ] AbstractCard -> Card (first small part https://invent.kde.org/frameworks/kirigami/-/merge_requests/1301)
- [ ] Card -> ActionCar...There is still some API to remove, therefore it needs to happen before freeze, proposals are:
# Cards
- [ ] AbstractCard -> Card (first small part https://invent.kde.org/frameworks/kirigami/-/merge_requests/1301)
- [ ] Card -> ActionCard
- [ ] CardsListView: Perhaps to keep https://invent.kde.org/frameworks/kirigami/-/merge_requests/1265
- [x] CardsGridView: Delete https://invent.kde.org/frameworks/kirigami/-/merge_requests/1312
# Actions
- [ ] Action: remove visibleChildren
- [ ] Migrate to An attached property over standard actions instead (ActionExt?): this can happen after 6.0, but is necessary to have all the action API ported over standard QQC.Action beforehand
# Other
- [ ] DelegateRecycler: delete, port the usages connected with the DragHandle to:
```qml
delegate: Loader {
required property var model
required property int index
sourceComponent: delegateComponent
}
```
# Drawers
- [ ] OverlayDrawer -> can handle-related API be just hidden for now? https://invent.kde.org/frameworks/kirigami/-/merge_requests/1268
- [ ] ContextDrawer: delete
- [ ] GlobalDrawer: remove banner* properties https://invent.kde.org/frameworks/kirigami/-/merge_requests/1266
- [ ] GlobalDrawer: hide properties about the handle, which would belong to the toolbar insteadhttps://invent.kde.org/frameworks/kirigami/-/issues/34make CardsGridView and Card customizable2022-10-30T09:51:48ZMatej Starcmatej.starc@protonmail.commake CardsGridView and Card customizableCurrent CardsGridView and Card (and its templates) widgets do not provide the customizability that other frameworks provide (web frameworks, for example: electron, vue.js, etc.). Yes, I know that Qt is not the same as them, but currently...Current CardsGridView and Card (and its templates) widgets do not provide the customizability that other frameworks provide (web frameworks, for example: electron, vue.js, etc.). Yes, I know that Qt is not the same as them, but currently CardsGridView only properly supports Kirigami.Card that has preset size. If your image has too big of a size, it will glitch the entire UI ([bug report](https://bugs.kde.org/show_bug.cgi?id=441672)), or you can't easily set how big the cards should be (maybe because of certain limitations that I do not know of ?). This introduces problems with consistency, which is one of KDEs goals. App developers not being able to use these widgets properly only means that they will either:
- not use this framework,
- have to make their own implementation, which of course introduces inconsistency with other apps, which was briefly addressed by Niccolò Ve in his [video](https://youtu.be/0mzm75RGWCc?t=251).https://invent.kde.org/frameworks/kirigami/-/issues/67Kirigami: The next and only GUI framework for KDE2023-10-24T21:12:24ZAndy BettsKirigami: The next and only GUI framework for KDEDuring discussion in the VDG channel, it was proposed that we focus our efforts in supporting and enhancing Kirigami in a way that it becomes the only GUI framework, or framework of choice for KDE software. The status quo is not sustaina...During discussion in the VDG channel, it was proposed that we focus our efforts in supporting and enhancing Kirigami in a way that it becomes the only GUI framework, or framework of choice for KDE software. The status quo is not sustainable for a number of reasons listed below:
### Problems with the status quo
1. Developers work with multiple GUI frameworks right now (QtWidgets, Kirigami, Plasma Components) leading to high work duplication and bifurcation of skill sets; some developers only know how to work with QML and others only know how to work with QtWidgets, limiting collaboration
2. Having a QStyle being the source of truth for apps' visual styling imposes a high technical bar for making visual changes that designers generally cannot attain, and limits the styling and animations that can be used in non-QtWidgets GUIs
3. Plasma uses a different styling system entirely, which means more code, more bugs, and visual redesigns must be made in many places, which is too costly for a small community of developers
4. Inability to quickly pivot and work on new technologies
### Benefits
1. Focused work in one framework; more eyeballs on the same code and everyone learns a common set of skills
2. Apps generally look better and more modern
3. Apps become mobile-ready by design
4. Styling changes can be made in one place
5. Expanded set of styles and animations can be used compared to QtWidgets apps
6. Changes to apps' GUIs are easier to make
7. Forces code to be split between GUI and business logic
8. Custom components are easier to create
9. Kirigami will have a clear future as a technology
### Challenges
1. Kirigami needs to support common components used widely in QtWidgets apps, such as a standard customizable toolbar, a standard shortcuts editor, in-window menubars with a standard menu item structure, traditional tab bars, tear-off docks, the entire KParts infrastructure, KHamburgerMenu, etc.
2. Memory usage and GUI responsiveness of QML software is generally worse than that of QtWidgets software unless extra work is done to address those issues
3. Being GPU-accelerated adds a vulnerability to bugs caused by graphics drivers that does not exist for QtWidgets apps
4. Crash backtraces are often incomprehensible due to crashing deep in the JavaScript interpreter, QML engine, or graphics drivers
5. Many KDE developers do not yet see the benefits of QML and Kirigami, and we would need to interview them regarding their concerns and address them one by one
6. QtQuick is still somewhat immature in Qt; major changes were made in Qt 4 -> 5, and again in 5 -> 6, which generally makes porting to a new major version more challenging than porting a QtWidgets app
7. Porting apps' GUI components from QtWidgets to Kirigami is a huge task that needs time and resources
Public discussion happening here: https://discuss.kde.org/t/we-need-your-thoughts-on-kirigami/6115https://invent.kde.org/frameworks/kirigami/-/issues/37KF6: The future of widgets2023-06-21T15:13:01ZMatej Starcmatej.starc@protonmail.comKF6: The future of widgetsI am creating this discussion to talk about the future of Kirigami's widgets (list items, etc.).
Example topics:
- to remove/replace with something else (which widget could be removed or replaced with an alternative.)
- to improve (what ...I am creating this discussion to talk about the future of Kirigami's widgets (list items, etc.).
Example topics:
- to remove/replace with something else (which widget could be removed or replaced with an alternative.)
- to improve (what improvement you suggest. Visual? Performance?)
- to change (suggest changing a widget in a certain way)
------------------------------------------------------------------------
**[Topic points]**
- Widget (widget name. Either a broad name or a specific widget name):
- (optional) Widget usage (where is the widget used):
- Issue:
- What to change:
- What does it bring to the table:
------------------------------------------------------------------------KF6https://invent.kde.org/frameworks/kirigami/-/issues/53KF6: PagePool API2023-06-29T12:52:56Zivan tkachenkoKF6: PagePool APIPagePool provides singletons of pages per URLs. It has multiple properties and methods to load new pages, manage loaded ones, and inspect what's loaded. However, those properties and notification signals can be improved to be more atomic...PagePool provides singletons of pages per URLs. It has multiple properties and methods to load new pages, manage loaded ones, and inspect what's loaded. However, those properties and notification signals can be improved to be more atomic and ergonomic.
First of all, given that this component is implemented in C++, [operates on pointers to QQuickItem objects](https://invent.kde.org/frameworks/kirigami/-/merge_requests/1136) and does NOT use any Page-specific properties, maybe it should be renamed to reflect that it's a generic Item cache.
For properties, my suggestions is to unify `lastLoadedUrl` and `lastLoadedItem` into some kind of Q_GADGET so that they are atomic and share a common notify signal.
It would be cool to use QQmlPropertyMap for urls->items mapping, but unfortunately it only supports strings as keys. Another idea was to use [ECMAScript Map](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map) class but there is no way to make it immutable for QML/JS (except to construct a new one on every READ call).
The `PagePool::resolvedUrl` method is too magical and better be removed. It is responsibility of the caller to ensure that URL is valid and resolved.
For another pure-QML type supplementing PagePool API, `PagePoolAction`, I have something to say about almost every property:
- ```qml
// This property holds the url or filename of the page that this action will load.
property string page
```
Clearly this can not hold a real `url` object. And as I said about `PagePool` itself, automagic URL resolution should be dropped completely in favor of client-side explicit resolutions.
- [ ] `property Item pageStack` — quite loosely typed. Why not use a `PageRow` instead of plain `Item`?
- [ ] `property Kirigami.PagePool pagePool` — this should probably be `required`. There is no way this component can work without an externally provided page pool. Maybe default page pool should be embedded into ApplicationWindow/ApplicationItem?
- [x] `property QQC2.Page basePage` — using styled `QQC2.*` components as types is a bad practice. It rarely adds anything useful to the type, but restricts any custom `T.Page` implementations. Unless it was meant to be specifically `Kirigami.Page`… <https://invent.kde.org/frameworks/kirigami/-/merge_requests/1146>
- [ ] `property var initialProperties` — it's weird and inefficient to have a declarative properties map that is only ever accessed in procedural code (`onTriggered` signal handler). It means that it keeps updating itself whenever any of bound object/properties change, and also means that it is a race condition between this Action's own `onTriggered` handler and possible other handlers in downstream code that may attempt to modify this map. Not to mention that it needs to actually keep that map in memory the whole time! A better solution would be to have an overridable method whose default implementation would return an empty map or `null`, like this:
```qml
// PagePoolAction.qml:
function getInitialProperties(): var {
return null;
}
// app.qml
footer: Kirigami.NavigationTabBar {
actions: [
Kirigami.PagePoolAction {
function getInitialProperties(): var {
const props = new Map();
props.set("data", root.computationallyExpensiveCall(data.source));
return props;
}
}
]
}
```
- [ ] All methods should have type hints.ivan tkachenkoivan tkachenkohttps://invent.kde.org/frameworks/kirigami/-/issues/55KF6: P.ActionIconGroup API2023-06-29T16:28:58Zivan tkachenkoKF6: P.ActionIconGroup APIThe `property string source` should be a `url`, not a `string`.
Now, I don't know exactly why does this group exists as a pure QML component. But with addition of [custom named gadget types in Qt 6.5](https://doc.qt.io/qt-6/qtqml-cppint...The `property string source` should be a `url`, not a `string`.
Now, I don't know exactly why does this group exists as a pure QML component. But with addition of [custom named gadget types in Qt 6.5](https://doc.qt.io/qt-6/qtqml-cppintegration-definetypes.html#registering-value-types) this whole thing should be ported to C++ for the lack of better options (and by that I mean, AbstractButton::icon group is still in a private header).KF6ivan tkachenkoivan tkachenkohttps://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/57KF6: Consider porting Kirigami.Theme to QQuickAttachedPropertyPropagator2023-07-04T12:19:05Zivan tkachenkoKF6: Consider porting Kirigami.Theme to QQuickAttachedPropertyPropagatorSince Qt 6.5 QtQuickControls2 module introduces `QQuickAttachedPropertyPropagator` public base class for attached objects with inheritance features like `Material`, `Universal` and other styles.
It looks like a good fit for `Kirigami.Th...Since Qt 6.5 QtQuickControls2 module introduces `QQuickAttachedPropertyPropagator` public base class for attached objects with inheritance features like `Material`, `Universal` and other styles.
It looks like a good fit for `Kirigami.Theme`, which is explicitly based on inheritance (and which [at times gets broken](https://bugs.kde.org/show_bug.cgi?id=459071) by either silenced parent change events or some other QtQuick magic which only upstream Qt classes like this one are able to access).
Also, it can be considered for `Kirigami.ScenePosition` to use closest parent as a caching point.KF6ivan tkachenkoivan tkachenkohttps://invent.kde.org/frameworks/kirigami/-/issues/47Incorrect code2023-05-02T18:10:27ZMatej Starcmatej.starc@protonmail.comIncorrect codeEver since looking into ActionToolBar and the components it uses, I saw quite a lot of code that does not make any sense (at least to me). This issue contains a list of files/lines of code that need to be checked upon because they either...Ever since looking into ActionToolBar and the components it uses, I saw quite a lot of code that does not make any sense (at least to me). This issue contains a list of files/lines of code that need to be checked upon because they either make no sense (ex. ActionsMenuItem line 14: ``action.visible === undefined || action.visible``) or can be improved upon.KF6