Whenever I see a Kirigami.Overlaysheet, I wonder why it was used instead of a window. The reasons for this are many:
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.
They can’t be moved.
They can’t be resized.
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):
initially appears to make sense, especially considering
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.
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.
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.
@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.
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.
@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 <iframe>-like reuse is achievable via a different method, I’ll probably instead care about that, but I do not see these components offered in another format.
I know iframe is kinda special in that it provides isolation between frames of a web page. In native apps running on your computer we’ll never have that kind of separation. So the analogy doesn’t quite apply. Instead we can only put <div> inside another <div>, so to speak. Which is exactly what Widgets and QtQuick are already doing! Just stack some QWidget inside another QWidget, and declare or dynamically create and reparent an Item inside another Item. So I would like to know what are you getting from KParts which you can’t get by just loading a library of widgets/items and instantiating some “main” one of them and reparenting into your app?
Or is your point mostly about bringing KWrite widget into a QtQuick scene?
It was merely an example of a way to embed a separate entity into another - additional properties of any referenced implementation, like isolation, are of no consequence to this (I’d actually prefer no isolation, so it’s irrelevant).
All I care about is being able to utilize the components which the KParts provide. Can that be accomplished without using KParts? I’ve no specific interest in this method of embedding them, if that’s all that they are - one of multiple.
I would love to provide more technical answers, but I’m just not proficient enough at Qt yet (partially owing to not being able to create the applications I want without this feature, lest I reimplement a huge amount myself).