Kirigami issueshttps://invent.kde.org/frameworks/kirigami/-/issues2023-10-24T21:12:24Zhttps://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/65Follow-up from "Introduce new API for list item contents"2023-10-04T19:05:02ZArjen HiemstraFollow-up from "Introduce new API for list item contents"The following discussion from !1073 should be addressed:
- [ ] @sporknife started a [discussion](https://invent.kde.org/frameworks/kirigami/-/merge_requests/1073#note_767310):
> ````suggestion:
> * @note If you don't need a s...The following discussion from !1073 should be addressed:
- [ ] @sporknife started a [discussion](https://invent.kde.org/frameworks/kirigami/-/merge_requests/1073#note_767310):
> ````suggestion:
> * @note If you don't need a subtitle, use `CheckDelegate` directly.
> ````https://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/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/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/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/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/54develop.kde.org place for the porting guide to live2023-06-27T09:38:03ZNate Grahamdevelop.kde.org place for the porting guide to liveRight now we have https://invent.kde.org/frameworks/kirigami/-/wikis/Porting-applications-to-KF6-version-of-Kirigami, which is an internal wiki, and doesn't seem super suitable for pointing 3rd-party devs at. We should create some extern...Right now we have https://invent.kde.org/frameworks/kirigami/-/wikis/Porting-applications-to-KF6-version-of-Kirigami, which is an internal wiki, and doesn't seem super suitable for pointing 3rd-party devs at. We should create some external-developer-focused documentation for this on develop.kde.org. We've got this going for the Plasma widget changes that need 3rd-party devs to adapt their code and I think it's a bit friendlier and more actionable as a result; see https://develop.kde.org/docs/plasma/widget/porting_kf6. It could live at https://develop.kde.org/docs/getting-started/kirigami/.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/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/50Avatar: actions.secondary can be removed?2023-06-21T00:57:38Zivan tkachenkoAvatar: actions.secondary can be removed?According to my local search through all the 170+ KDE projects that I have cloned, `actions.secondary` does not appear anywhere. Moreover, this is such a niche feature that it probably does not belong in a generic Kirigami component. Thi...According to my local search through all the 170+ KDE projects that I have cloned, `actions.secondary` does not appear anywhere. Moreover, this is such a niche feature that it probably does not belong in a generic Kirigami component. Think about it: it is specifically designed to take a fixed amount of space at the bottom of an Avatar, and adds up a considerable amount of code complexity to mouse area and state management.
The whole `AvatarGroup` class could be removed then too. Or otherwise at least be downgraded to a `Q_GADGET` instead of `Q_OBJECT`, and upgraded with `QObject *` property types instead of QVariant.KF6ivan tkachenkoivan tkachenkohttps://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/48Inconsistent delection of KIRIGAMI_LOWPOWER_HARDWARE2023-06-05T11:10:08Zivan tkachenkoInconsistent delection of KIRIGAMI_LOWPOWER_HARDWARE```
Searching 207 files for "KIRIGAMI_LOWPOWER_HARDWARE"
~/kde/src6/kirigami/src/shadowedrectangle.cpp:
311
312 // Cache lowPower state so we only execute the full check once.
313: static bool lowPower = QByteAr...```
Searching 207 files for "KIRIGAMI_LOWPOWER_HARDWARE"
~/kde/src6/kirigami/src/shadowedrectangle.cpp:
311
312 // Cache lowPower state so we only execute the full check once.
313: static bool lowPower = QByteArrayList{"1", "true"}.contains(qgetenv("KIRIGAMI_LOWPOWER_HARDWARE").toLower());
314 if (m_renderType == RenderType::LowQuality || (m_renderType == RenderType::Auto && lowPower)) {
315 shadowNode->setShaderType(ShadowedRectangleMaterial::ShaderType::LowPower);
~/kde/src6/kirigami/src/shadowedtexture.cpp:
65 }
66
67: if (qEnvironmentVariableIsSet("KIRIGAMI_LOWPOWER_HARDWARE")) {
68 shadowNode->setShaderType(ShadowedRectangleMaterial::ShaderType::LowPower);
69 }
2 matches across 2 files
```
There are two pieces of code to check for `KIRIGAMI_LOWPOWER_HARDWARE` environment variable, and they do it differently.
Suggestion is to factor them out into a single (preferably public) function with a static bool variable in it.
Also, it seem that in Qt internals the convention is to use `qEnvironmentVariableIntValue` which both checks for presence and for non-zero value. IMHO we should just drop that any-cased "true" string support. Just do it one way, and do it good.KF6Arjen HiemstraArjen Hiemstrahttps://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.KF6https://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/43ActionToolBar in KCM is broken in Qt62023-03-03T16:05:45ZNicolas FellaActionToolBar in KCM is broken in Qt6Several KCMs, e.g. colors, icons, cursor, style, have Kirigami.ActionToolBar in a footer.
In Qt6 this results in the footer being not visible.
There's warnings like
```
kf.kirigami: Failed to find a Kirigami platform plugin
kf.kirigam...Several KCMs, e.g. colors, icons, cursor, style, have Kirigami.ActionToolBar in a footer.
In Qt6 this results in the footer being not visible.
There's warnings like
```
kf.kirigami: Failed to find a Kirigami platform plugin
kf.kirigami: Could not create delegate for ToolBarLayout
kf.kirigami: file:///home/nico/kde6/usr/lib64/qml/org/kde/kirigami.2/ActionToolBar.qml: Maximum call stack size exceeded.
kf.kirigami: Could not create delegate for ToolBarLayout
kf.kirigami: file:///home/nico/kde6/usr/lib64/qml/org/kde/kirigami.2/ActionToolBar.qml: Maximum call stack size exceeded.
kf.kirigami: Could not create delegate for ToolBarLayout
kf.kirigami: file:///home/nico/kde6/usr/lib64/qml/org/kde/kirigami.2/ActionToolBar.qml: Maximum call stack size exceeded.
kf.kirigami: Could not create delegate for ToolBarLayout
kf.kirigami: file:///home/nico/kde6/usr/lib64/qml/org/kde/kirigami.2/ActionToolBar.qml: Maximum call stack size exceeded.
kf.kirigami: Could not create delegate for ToolBarLayout
kf.kirigami: file:///home/nico/kde6/usr/lib64/qml/org/kde/kirigami.2/ActionToolBar.qml: Maximum call stack size exceeded.
```https://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/41Dialog does not respect footer implicit width2023-02-21T11:00:26Zivan tkachenkoDialog does not respect footer implicit widthKirigami Dialog, being a QQC2 Templates Dialog, is expected to follow implicit size of its content, header and footer. Also, by extension being a QQC2 Popup, it would ensure that it does not grow too large that it does not fit into its p...Kirigami Dialog, being a QQC2 Templates Dialog, is expected to follow implicit size of its content, header and footer. Also, by extension being a QQC2 Popup, it would ensure that it does not grow too large that it does not fit into its parent window.
Default QQC2 style implementation specifies the following sizing expressions:
```qml
implicitWidth: Math.max(implicitBackgroundWidth + leftInset + rightInset,
contentWidth + leftPadding + rightPadding,
implicitHeaderWidth,
implicitFooterWidth)
implicitHeight: Math.max(implicitBackgroundHeight + topInset + bottomInset,
contentHeight + topPadding + bottomPadding
+ (implicitHeaderHeight > 0 ? implicitHeaderHeight + spacing : 0)
+ (implicitFooterHeight > 0 ? implicitFooterHeight + spacing : 0))
```
But Kirigami overrides with lots of its own magic, and no header/footer for implicitWidth:
```qml
// calculate dimensions
implicitWidth: contentItem.implicitWidth + leftPadding + rightPadding // maximum width enforced from our content (one source of truth) to avoid binding loops
implicitHeight: contentItem.implicitHeight + topPadding + bottomPadding
+ (implicitHeaderHeight > 0 ? implicitHeaderHeight + spacing : 0)
+ (implicitFooterHeight > 0 ? implicitFooterHeight + spacing : 0);
```
This doesn't quite work for dialogs with standard buttons, and the implicit width of DialogButtonBox is just disregarded. Adding to the mix a semi-broken implementation of DialogButtonBox in qqc2-desktop-style, which doesn't respect explicitly given width, we get this picture:
![image](/uploads/eb01c5ed259ad8187a5fdc2ad09a8323/image.png)
This is a screenshot of ChangeWalletPassword.qml from Users KCM, patched to use `customFooterActions` instead of custom 1-column GridLayout. Also, as far as I can tell, there is no way to scroll it horizontally either, despite the fact that the buttons are supposed to land in a horizontal ListView.
So, if we patch Kirigami.Dialog to account for footer like this:
```diff
// calculate dimensions
- implicitWidth: contentItem.implicitWidth + leftPadding + rightPadding // maximum width enforced from our content (one source of truth) to avoid binding loops
+ implicitWidth: Math.max(
+ contentItem.implicitWidth + leftPadding + rightPadding, // maximum width enforced from our content (one source of truth) to avoid binding loops
+ implicitHeaderWidth,
+ implicitFooterWidth)
footer: T.Control {
id: footerToolBar
- property bool bufferMode: contentItem.implicitHeight === 0
- implicitHeight: bufferMode ? Kirigami.Units.smallSpacing : contentItem.implicitHeight
+ property bool bufferMode: implicitContentHeight === 0
+ implicitHeight: bufferMode ? Kirigami.Units.smallSpacing :
+ Math.max(implicitContentHeight + topPadding + bottomPadding,
+ implicitBackgroundHeight + topInset + bottomInset)
+ implicitWidth:
+ Math.max(implicitContentWidth + leftPadding + rightPadding,
+ implicitBackgroundWidth + leftInset + rightInset)
```
…then I get a perfectly sized dialog like this:
![image](/uploads/d0d20a9046899b6511fe23d72597f905/image.png)
and AFAICT I don't get any new binding loops. Not sure what that comment about "one source of truth" was referring to.
On the other hand, I don't quite understand why upstream code uses explicit content height instead of implicit counterparts.ivan tkachenkoivan tkachenkohttps://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.https://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:
------------------------------------------------------------------------KF6