Kirigami: The next and only GUI framework for KDE
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
- 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
- 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
- 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
- Inability to quickly pivot and work on new technologies
Benefits
- Focused work in one framework; more eyeballs on the same code and everyone learns a common set of skills
- Apps generally look better and more modern
- Apps become mobile-ready by design
- Styling changes can be made in one place
- Expanded set of styles and animations can be used compared to QtWidgets apps
- Changes to apps' GUIs are easier to make
- Forces code to be split between GUI and business logic
- Custom components are easier to create
- Kirigami will have a clear future as a technology
Challenges
- 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.
- 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
- Being GPU-accelerated adds a vulnerability to bugs caused by graphics drivers that does not exist for QtWidgets apps
- Crash backtraces are often incomprehensible due to crashing deep in the JavaScript interpreter, QML engine, or graphics drivers
- 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
- 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
- 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/6115
Edited by Nate Graham