# Why does Kirigami.Overlaysheet exist? **URL:** \ **Category:** Help\ **Tags:** plasma, kirigami\ **Created:** [April 11, 2024, 5:02pm UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920 "2024-04-11T17:02:02Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![rokejulianlockhart](https://discuss-cdn.kde.org/user_avatar/discuss.kde.org/rokejulianlockhart/32/29718_2.png) [@rokejulianlockhart](https://discuss.kde.org/u/rokejulianlockhart)\ **Post date:** [April 11, 2024, 5:02pm UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/1 "2024-04-11T17:02:02Z")
> [@Can QML fake windows be resized?](https://discuss.kde.org/t/can-qml-fake-windows-be-resized/3109/1): > > > ![image](https://discuss-cdn.kde.org/uploads/default/original/2X/8/843d91b52bca025dd3cd282ca376d7291a62b5f8.png) Whenever I see a `Kirigami.Overlaysheet`, I wonder why it was used instead of a window. The reasons for this are many: 1. They reimplement the window decorations, meaning that none of the customizations are utilized, so they appear very visually inconsistent, and can’t be controlled like regular windows. 2. They can’t be moved. 3. They can’t be resized. 4. They don’t have shadows - instead, they darken the entirety of the background window. This is optional for regular windows, and user-configurable. In a relevant conversation, I asked about this, and got a _response_, although not something I’d consider an answer (not that that’s problematic): > [@Can QML fake windows be resized?](https://discuss.kde.org/t/can-qml-fake-windows-be-resized/3109/4): > > > [@Can QML fake windows be resized?](https://discuss.kde.org/t/can-qml-fake-windows-be-resized/3109/3): > > > > Any reason why the license isn’t just displayed in a regular window? > > The reason is because Qt Quick doesn’t make it very easy to open additional windows, it’s possible, but it’s a pain. It’s much easier to use overlay sheets (and the behavior is more predictable, e.g. on mobile devices, which we also support.) initially appears to make sense, especially considering > [@We need your thoughts on Kirigami](https://discuss.kde.org/t/we-need-your-thoughts-on-kirigami/6115/20): > > Qt Quick feels like it’s made for companies that have a very good idea of what their target device is, and that want to provide a custom (probably embedded) company-branded UI to users. Desktop and common look&feel across apps was and is an afterthought for Qt Quick. Basic controls such as lists and comboboxes require me to copy and paste code to calculate text metrics so that at least my initial set of text items doesn’t get cut off. > > I’m looking to Kirigami to help me with making a standard app that looks & feels “right” across desktops, where the easy way to use it is also the one that works well out of the box. But the navigation components make for a poor default experience, abstractions are leaky, and in the end I need to hardcode lots of stuff that I know will break for a user with non-standard setup. > > Kirigami is not the best at mobile, it’s not the best at “custom branded” cross-platform, and it’s not particularly great at guiding users towards making a decent “standard” open source desktop app. It gets you some improvements over the poor state of Qt Quick, and that’s a good reason to include it if you’ve already decided to use that because QWidgets is on life support. KDE obviously nudges apps towards Kirigami so that’s a handful of developers that will use it no matter what. But no hero use case(s) to get excited about. However, I’m still surprised that they are appearing to become increasingly more prevalent. Is KWin fundamentally incapable of properly scaling windows on mobile devices to be full-screen for a reason complex and unbenknownst to me? They just appear to provide the worst experience possible to both desktop and mobile users. ---
**Author:** ![Leopold](https://discuss-cdn.kde.org/letter_avatar_proxy/v4/letter/l/6bbea6/32.png) [@Leopold](https://discuss.kde.org/u/Leopold)\ **Post date:** [April 11, 2024, 10:31pm UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/2 "2024-04-11T22:31:38Z")
There seems to already be discussion among KDE developers favoring native windows, which is a good sign that this could change in the medium term: [Settle on a dialog design (#41) · Issues · Teams / KDE Visual Design Group / Issues · GitLab](https://invent.kde.org/teams/vdg/issues/-/issues/41) However, there are still in my eyes many unresolved problems with Kirigami, which makes me worry a little about the push to convert so much of KDE to it. In particular, the lack of the powerful movable and customizable toolbars from KXmlGui is what I would consider hurts the most. These toolbars are offered by the vast majority of KDE’s QtWidgets applications and I frequently take advantage of their customizability. Other significant omissions include QDockWidget, the keyboard shortcut dialog, KParts and KHamburgerMenu. I’m cautiously optimistic that Kirigami will in time begin to approach the massive power currently offered by QtWidgets + KDE Frameworks. However, it seems a lot of work will be required to get there. As it stands, Kirigami doesn’t seem to be suitable for the more powerful and complex applications KDE is partly known for, such as Kdenlive, Digikam, Krusader, KDevelop, Kontact, Krita or Calligra. Particularly the latter two, as their interfaces are practically built around QDockWidget. ---
**Author:** ![rokejulianlockhart](https://discuss-cdn.kde.org/user_avatar/discuss.kde.org/rokejulianlockhart/32/29718_2.png) [@rokejulianlockhart](https://discuss.kde.org/u/rokejulianlockhart)\ **Post date:** [April 12, 2024, 11:14am UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/3 "2024-04-12T11:14:32Z")
> [@Leopold](#): > > Other significant omissions include QDockWidget, the keyboard shortcut dialog, KParts and KHamburgerMenu. @Leopold, there isn’t KPart support in Kirigami?! That’s one of KDE’s biggest selling points in my eyes - being able to reutilize GUI implementations of functionality like any CLI application would, as if the developer were using `iframe`s in HTML. Just imagine if Dolphin utilized its own Konsole implementation, like [GitHub - microsoft/vscode: Visual Studio Code](https://github.com/microsoft/vscode) and [GitHub - microsoft/terminal: The new Windows Terminal and the original Windows console host, all in the same place!](https://github.com/microsoft/terminal) do. Do you know of an enhancement at [bugs.kde.org](http://bugs.kde.org) requesting support? ---
**Author:** ![ngraham](https://discuss-cdn.kde.org/user_avatar/discuss.kde.org/ngraham/32/64_2.png) [@ngraham](https://discuss.kde.org/u/ngraham)\ **Post date:** [April 12, 2024, 6:47pm UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/4 "2024-04-12T18:47:23Z")
No need to file a bug report for KParts support in Kirigami. Everyone involved knows about the omission. The problem is not tracking it but rather figuring out if and how to address it. ---
**Author:** ![rokejulianlockhart](https://discuss-cdn.kde.org/user_avatar/discuss.kde.org/rokejulianlockhart/32/29718_2.png) [@rokejulianlockhart](https://discuss.kde.org/u/rokejulianlockhart)\ **Post date:** [April 17, 2024, 4:55pm UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/5 "2024-04-17T16:55:00Z")
> [@ngraham](#): > > Everyone involved knows about the omission. @ngraham, I always thought that was a reason to file something - so that all with a stake would know when it’s remediated. For instance, it’s preventing me starting a project, so I’d like to know when it’s done, and won’t know otherwise unless it’s tracked _somewhere_. ---
**Author:** ![Leopold](https://discuss-cdn.kde.org/letter_avatar_proxy/v4/letter/l/6bbea6/32.png) [@Leopold](https://discuss.kde.org/u/Leopold)\ **Post date:** [April 17, 2024, 6:41pm UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/6 "2024-04-17T18:41:56Z")
This is true. Bug reports aren’t only helpful for the developers of any given application or library, they’re also useful for their users to see the status any specific feature or bug that might affect them. If I remember correctly, before KleverNotes became a KDE project, the developer spent a long time trying to figure out how to embed MarkdownPart in Kirigami before concluding it was impossible and using QtWebEngine instead. An open bug report on the issue tracker would have made this immediately clear. ---
**Author:** ![ngraham](https://discuss-cdn.kde.org/user_avatar/discuss.kde.org/ngraham/32/64_2.png) [@ngraham](https://discuss.kde.org/u/ngraham)\ **Post date:** [April 17, 2024, 7:45pm UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/7 "2024-04-17T19:45:23Z")
Sure, if you think it would be helpful for other people to track, go ahead. ---
**Author:** ![rokejulianlockhart](https://discuss-cdn.kde.org/user_avatar/discuss.kde.org/rokejulianlockhart/32/29718_2.png) [@rokejulianlockhart](https://discuss.kde.org/u/rokejulianlockhart)\ **Post date:** [April 17, 2024, 10:08pm UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/8 "2024-04-17T22:08:04Z")
> [@ngraham](#): > > Sure, if you think it would be helpful for other people to track, go ahead. Thanks lots, @ngraham. I’ll do so, since [Bug List](https://bugs.kde.org/buglist.cgi?quicksearch=kpart%20support%20kirigami&list_id=2686418) returns 0 results. ---
**Author:** ![rokejulianlockhart](https://discuss-cdn.kde.org/user_avatar/discuss.kde.org/rokejulianlockhart/32/29718_2.png) [@rokejulianlockhart](https://discuss.kde.org/u/rokejulianlockhart)\ **Post date:** [April 17, 2024, 10:12pm UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/9 "2024-04-17T22:12:24Z")
Done at [485702 – KPart support in Kirigami](https://bugs.kde.org/show_bug.cgi?id=485702#c0). I hope that I’ve kept it adequately succinct and accurate. ---
**Author:** ![ratijas](https://discuss-cdn.kde.org/user_avatar/discuss.kde.org/ratijas/32/60_2.png) [@ratijas](https://discuss.kde.org/u/ratijas)\ **Post date:** [May 3, 2024, 2:28pm UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/10 "2024-05-03T14:28:45Z")
Hi, I’m somewhat knowledgeable about the QtQuick stack, but I’m not an expert in QtWidgets by any means. It might be useful to state what is so special about KParts, and which features do you want to see in QtQuick apps? ---
**Author:** ![rokejulianlockhart](https://discuss-cdn.kde.org/user_avatar/discuss.kde.org/rokejulianlockhart/32/29718_2.png) [@rokejulianlockhart](https://discuss.kde.org/u/rokejulianlockhart)\ **Post date:** [May 3, 2024, 3:51pm UTC](https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/11 "2024-05-03T15:51:28Z")
> [@ratijas](#): > > It might be useful to state what is so special about KParts, and which features do you want to see in QtQuick apps? @ratijas, if you’re asking me, it’s merely the ability to utilize the powerful components which Kate, KWrite, and Konsole provide so that I don’t have to duplicate their functionality. For instance, like Konqueror does, were I to want to write a file manager, I’d be able to reuse the Dolphin KPart, allowing me to focus upon the surrounding GUI, and contribute (and benefit from contributions) to that shared component. This would allow the FM to be familiar to a Dolphin user. Likewise, were I to design anything with text fields, I’d undoubtedly use the KWrite KPart for all of them, because it’s so much more powerful than an edit or input form without those controls that the KPart provides. If this `