Kirigami2 for developement on Windows [Rant]


a short foreword: i had to cripple all my links because as a new user i am not allowed to use a lot of links. All links have a \prepended, remove it if you want to open it.

So, i am currently working on a cross platform application, that’s supposed to run on windows and linux. I do have some experience with Qt Widgets, but not a lot of knowledge about QML and have just recently found out about the KDE frameworks. I was particularly interested in kirigami, because i like the look of apps built with it.

Now i found this (\, a kde frameworks overview, that talks about kirigami2 being functional on windows. But when i was reading through the getting started (\ documentation of kirigami, i was a little surprised to find info exclusively about linux distros.

So i decided to just clone the repo and build it myself. There was a dependency, and that was ECM. No idea why these extra cmake modules are required, but ok. So i cloned ECM, build it, had some dependencies like python and something that was called sphynx or so. In the end i could build ecm, install it to some directory and then build kirigami.

This all just to be able to see, that i need I18n and CoreAddons…
So i wanted to give up because for sure these all come with their own dependencies…
Just accidentially i found out about craft, that can install all these libs for me. Why is nobody refering to craft in the kirigami documentation?? Or at least when googling for ECM, this: (\ website could say something about craft on windows.

Whatever, i could now install all libs needed for the basic kirigami example (\ by using craft.

So, i made a project folder, added the files as described in the tutorial etc.
I hat do remove the ECM install i had manually done before, because cmake was always using the wrong version instead of the craft one. I added C:/CraftRoot/share/ECM/ to my CMAKE_PREFX_PATH and who would have believed it? I could actually build the application!

Now the excitement was only short, because i soon discovered, that other examples did not work as expected and somehow simple things are not working. E.g. the app from the main kirigami page(\

So all in all, i have to say getting something to run on windows is not great fun and i have wasted a few days just to get a framework running that does not work properly…

Now just for completeness, i want to say that i have used mingw for compiling, and i used Qt 5.15.2. I do also want to say that i have downloaded/installed the libs with craft, but builded my application out of a normal terminal. for execution i translated the file to a .bat and that did work for me.

Sorry for the lengthy text, but i was just getting frustrated with a framework i thought would solve problems for me, but in reality it was just a pain and the result is not so nice.
I have also seen that there is a recent thread (\ about why kirigami is not used a lot. I don’t know for linux, but i have a good idea why it’s not used for cross platform/windows. It really makes me wonder if it is meant to be run on windows, or if it is just a byproduct of being built with qt and its only technically compatible with windows but not really…

1 Like

From my own experiences with creating a Kirigami app that also works on Windows: The docs aren’t great, the result isn’t perfect but it is absolutely serviceable. I don’t know when or where I found craft, but I know I found it pretty much immediately so I didn’t have to spend time for nothing trying to build the dependencies manually and I don’t know why or how the default app looks this broken for you. There’s definitely some parts where Kirigami apps look kinda weird on Windows, but I’d say at least for me 95% of the look and feel translates correctly, just with some minor things like tab bars stretching the width of its container on Windows where they do not on Linux and some weird half written word with “…” at the end where there would be enough space to just write it out completely.

Here’s an example image of what I mean with it looks decent and serviceable:

The screenshot is from a while ago during development, but the general design hasn’t changed - containers, info boxes, inputs, buttons, icons, … all work and look decent enough. Is there a slight difference in layouting? Yes. Are some margins and paddings different on various input elements? Sure. Are icons a bit smaller and look a bit less sharp? Unfortunately. But is it still a decent looking and usable UI? Also yes.

That said, I don’t think that is necessarily bad as it feels to me that Kirigami is targeted to be Linux first while also supporting other platforms so an app made with it is not stuck to just be Linux only. I would definitely like to have some tutorial written out front to back on how to build a Kirigami app on Windows (I guess I could be the change I want to see in the world in this case) and not having to piece together the information step by step from various different KDE (or Qt generic) tutorials and obviously it would be great if the result would be 100% in line with how it looks on Linux, but all things considered Kirigami is still a fairly small framework by the looks of it, so I expect things to not be perfect.

I do think that you are correct when saying that it is targeted towards linux and that this is the reason why it’s not 100% in line with how it performs on linux.
But for me it is far away from 100%, it’s simply not useable at the moment. Even though you seem to have a properly working toolchain using kirigami on windows, for me the overall experience is pretty bad.

If you or anyone else is willing to support me in getting a properly working setup, i’d be willing to write a tutorial for windows that shows how to get there.

Honestly, it might just be time that is the difference - right now there’s a big push for moving from Qt5 to Qt6 as a base and there’s a decent amount of breakage going on. I don’t know what versions of the framework craft currently compiles when you ask it to install (I’m still on Qt5/KF5). Apart from that I don’t think I did anything “special”, just compile Qt and the dependencies through craft, point my Qt Creator to the craft-created binaries and use it. Again, I don’t know the current status of versions on craft, so maybe nothing of that applies because it’s still the same/a working version, I keep it as a “I have no need to re-compile everything and it’s working now so I won’t touch it”.

I did need a small hack to get the breeze icons to work, which seems like it could be an issue for you since there’s some icons missing (but not all since the hamburger menu icon is there?).
Said hack is just including “KIconThemes” somewhere, as that forces the icons to be loaded on platforms that don’t ship them as part of the environment, like Windows (If I understood the explanation I got correctly). You also need to call some function for the compiler to not optimize it away, I solved that by using #include <KIconThemes/kicontheme.h> in my main.cpp and then calling KIconTheme::current(); as the first line in my main() function.

Unfortunately I have no idea why the header bar has different colors between buttons and background and why the “Hello” is shortened to “H…”, I just never had that happen on my end.

Also worth noting: I haven’t yet managed to actually deploy the program on Windows - it runs fine (albeit in some places a bit slower) when run from Qt Creator, but I can’t solve it refusing to load the Qt QPA platform plugin (even though it exists) when trying to run the .exe directly from file explorer.

1 Like

Yeah maybe it’s bad timing, for now i think i will now keep everything at standard qml and see what happens.

Regarding Breeze icons, i have tried what you mentioned, but it does not seem to make any difference.

Regarding the header bar, it seems that the length is not the reason, somehow it depends on the character. E.g. a way longer string

That’s very interesting, because i can run it outside of qt creator also. have you tried converting the in a .bat file? I do this, then call the bat file and after that the application from the same terminal.

In case you haven’t, you probably need to install breeze-icons via craft first (forgot to mention that, also, not entirely sure on the name of the package, it’s been a while since I installed it and am not near my dev machine right now)

I’ll look into the prefix to see if I messed up something there. I haven’t put in all that much time to get it to work standalone yet, was something I worked on literally the other day for an hour or so.

PS: Really interesting with the page title, will have to investigate that some more

Breeze icons are installed, that does not seem to be the problem, but thanks for your help!

Indeed, the page title behaves weirdly.

The page title looks like you’re using the Qt Quick “Basic” style. Maybe try building qqc2-desktop-style or qqc2-breeze-style. I’ve never done windows development before so I’m not sure how styling works on Windows, but on Linux I run the app like this QT_QUICK_CONTROLS_STYLE=org.kde.breeze my-app to launch it with the Breeze style.

@jackh i have not yet thought/heard about that. I have tried to set the QT_QUICK_CONTROLS_STYLE environment variable to org.kde.breeze and org.kde.desktop. Both result in the button surrounding disappearing.
But the buttons are still clickable.

The button outline disappearing is expected because these are tool buttons. Try adding a button in the main window area and it should look like a regular breeze button.

Regarding the icons I’m not sure what’s going on. I will try to set up a Windows dev environment at some point to see if I can reproduce these issues.

For me a basic button looks like the QtQuick.Controls.Basic one.

Can I ask how you even managed to build the helloworld app? I’m trying to follow the instructions for craft but I get this error when compiling

-- Build files have been written to: C:/_/1cb51a6c/build
*** Action: make for helloworld ***
executing command: C:\CraftRoot\dev-utils\bin\ninja.exe
[1/6] Automatic MOC for target helloworld
[2/6] Automatic RCC for resources.qrc
[3/6] Building CXX object src\CMakeFiles\helloworld.dir\helloworld_autogen\mocs_compilation.cpp.obj
[4/6] Building CXX object src\CMakeFiles\helloworld.dir\helloworld_autogen\EWIEGA46WW\qrc_resources.cpp.obj
[5/6] Building CXX object src\CMakeFiles\helloworld.dir\main.cpp.obj
[6/6] Linking CXX executable bin\helloworld.exe
*** Action: cleanimage for helloworld ***
*** Action: install for helloworld ***
executing command: C:\CraftRoot\dev-utils\bin\ninja.exe install
ninja: error: unknown target 'install', did you mean 'uninstall'?
Command ['C:\\CraftRoot\\dev-utils\\bin\\ninja.exe', 'install'] failed with exit code 1
Action: install for helloworld:master FAILED
*** Craft all succeeded: helloworld after 6 seconds ***
fatal error: package helloworld all failed
Craft stopped with out completing ['helloworld']

This is the source repo: Jack Hill / helloworld · GitLab
This is the craft repo: Jack Hill / craft-helloworld · GitLab
And this is the wiki page that I’m trying to follow: Craft/Blueprints - KDE Community Wiki

BTW I’m using MSVC so that might be an issue.

I realised it was because the example app CMake file doesn’t install the files. Fixed it now.

Okay so regarding the application style:

KDE has two Qt Quick styles: org.kde.breeze which is a native Qt Quick implementation of Breeze, or org.kde.desktop which proxies the current Qt Widgets style. Make sure you build the one you want with Craft.

You can set the style from the environment with (Powershell) $Env:QT_QUICK_CONTROLS_STYLE = "org.kde.breeze". Or you can set the style in the code like this:

if (qEnvironmentVariableIsEmpty("QT_QUICK_CONTROLS_STYLE")) {

This will attempt to use the Breeze style or fall back to Fusion if Breeze can’t be found.

Here is a screenshot of a basic app (the one I linked earlier) with Breeze theme enabled:


Very insteresting! I gave it a try and at first it was falling back to the Fallbacksyle. But then i got it working! Previously i have used craft breeze-icons to install breeze. I was not aware, that i had to also install the style itself with craft qqc2-breeze-style. So your example does now look the same for me!

My Application from before has also improved, but the icons are still not showing.

Regarding the blueprints, i have no idea what they are used for?

Yep I’m still trying to figure out the icons issue.

Blueprints are used to specify how to build your app with craft, e.g. I just run craft -i helloworld. I suppose you can also build it without craft in which case you can ignore all the stuff about blueprints.

So I tried to build Kirigami on windows directly. I am not using craft.
The ECM module was built without any issues but Kirigami is throwing an error when building.

[ 64%] Building CXX object src/CMakeFiles/KirigamiPlugin.dir/icon.cpp.obj
In file included from C:/mingw64/x86_64-w64-mingw32/include/windows.h:72,
                 from C:/Qt/6.6.0/mingw_64/include/QtCore/qt_windows.h:28,
                 from C:/Qt/6.6.0/mingw_64/include/QtGui/qopengl.h:13,
                 from C:/Qt/6.6.0/mingw_64/include/QtQuick/qsgtexture_platform.h:11,
                 from C:/Qt/6.6.0/mingw_64/include/QtQuick/qsgtexture.h:10,
                 from C:/Qt/6.6.0/mingw_64/include/QtQuick/qsgtexturematerial.h:8,
                 from C:/Qt/6.6.0/mingw_64/include/QtQuick/qsgsimpletexturenode.h:9,
                 from C:/Qt/6.6.0/mingw_64/include/QtQuick/QSGSimpleTextureNode:1,
                 from C:\Users\sanjay\Documents\Projects\KDE\kirigami\src\scenegraph/managedtexturenode.h:12,
                 from C:\Users\sanjay\Documents\Projects\KDE\kirigami\src\icon.cpp:9:
C:/mingw64/x86_64-w64-mingw32/include/winuser.h:2965:43: error: variable 'CreateSyntheticPointerDevice' definition is marked dllimport
      |                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/mingw64/x86_64-w64-mingw32/include/winuser.h:2965:72: error: 'POINTER_INPUT_TYPE' was not declared in this scope
      |                                                                        ^~~~~~~~~~~~~~~~~~
C:/mingw64/x86_64-w64-mingw32/include/winuser.h:2965:110: error: expected primary-expression before 'maxCount'
      |                                                                                                              ^~~~~~~~
C:/mingw64/x86_64-w64-mingw32/include/winuser.h:2965:120: error: 'POINTER_FEEDBACK_MODE' was not declared in this scope
      |                                                                                                                        ^~~~~~~~~~~~~~~~~~~~~
C:/mingw64/x86_64-w64-mingw32/include/winuser.h:2965:146: error: expression list treated as compound expression in initializer [-fpermissive]
      |                                                                                                                                                  ^
C:/mingw64/x86_64-w64-mingw32/include/winuser.h:2966:93: error: 'POINTER_TYPE_INFO' does not name a type; did you mean 'POINTER_64_INT'?
      |                                                                                             ^~~~~~~~~~~~~~~~~
      |                                                                                             POINTER_64_INT
mingw32-make[2]: *** [src\CMakeFiles\KirigamiPlugin.dir\build.make:854: src/CMakeFiles/KirigamiPlugin.dir/icon.cpp.obj] Error 1
mingw32-make[1]: *** [CMakeFiles\Makefile2:1730: src/CMakeFiles/KirigamiPlugin.dir/all] Error 2
mingw32-make: *** [Makefile:165: all] Error 2

I am not too sure what is causing the issue here. But it seems like it is issue in Icon.cpp

Also I am using gcc compiler to build it.

I have also tried to build ECM and Kirigami without using craft, but i have used Qt5. I did not continue to go down this path, because soon you will need things like CoreAddons, IconThemes etc. Then everytime you need something you need to invest some time to get things running.

So craft is way better, but unfortunately with craft, not everything seems to be 100% yet.

Does Kirigami depends on KCoreaddons? I have checked the CMakeLists of Kirigami it seems only ECM and Qt are required no?

No, you are correct, Kirigami does not depend on KCoreAddons, but i have followed this tutorial and they used it in their cmake file. I just wanted to say, that you’ll eventually need more than just the kirigami module.

I think you will at least need a style like qqc2-breeze-style or something like that. And you will eventually need the breeze-icons. But i have not got them working yet.

Looking back through what I did to get them working, I think I forgot to mention one step; I had to copy the iconTheme.rcc into a folder called “data” next to the final binary (I think I created the “data” folder). The iconTheme.rcc should be somewhere in the build files of breeze-icons:


That, together with #include-ing KIconTheme like I mentioned previously, should get breeze icons working on Windows (or rather: it did on my end and this time I’m fairly sure I forgot none of the steps)

1 Like