I’m trying to develop kirigami applications and I’m finding it nearly impossible to get things setup up correctly. I was developing something whilst on Arch for quite a while, but now am on NixOS and can’t get things setup correctly. I am trying to just at the very least get it to work without needing a nix-shell or nix develop environment so that I know how it’s supposed to look. I can get it to build and launch under nix develop, but it won’t pick up on plasma themes so I’m wanting to make sure it looks correctly with various themes.
Any help? I’m using plasma and here are the packages I have installed in my config file.
Also, I prefer not using qtcreator if that matters at all. I’m developing it with emacs and would really like to just call my compile commands from within there, but I can parse that out so long as I can figure out how to do it from a shell at least. Any ideas?
When attempting to build it without the nix-shell cmake can’t find certain packages.
-- Could NOT find KF5Kirigami2 (missing: KF5Kirigami2_DIR)
-- Could NOT find KF5Kirigami2: found neither KF5Kirigami2Config.cmake nor kf5kirigami2-config.cmake
-- Could NOT find KF5I18n (missing: KF5I18n_DIR)
-- Could NOT find KF5I18n: found neither KF5I18nConfig.cmake nor kf5i18n-config.cmake
-- Could NOT find KF5CoreAddons (missing: KF5CoreAddons_DIR)
-- Could NOT find KF5CoreAddons: found neither KF5CoreAddonsConfig.cmake nor kf5coreaddons-config.cmake
CMake Error at /nix/store/wavryx1qc6ym0vp897dqpx9sgzwr76wy-cmake-3.22.3/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find KF5 (missing: Kirigami2 I18n CoreAddons)
Call Stack (most recent call first):
/nix/store/wavryx1qc6ym0vp897dqpx9sgzwr76wy-cmake-3.22.3/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
/run/current-system/sw/share/ECM/find-modules/FindKF5.cmake:93 (find_package_handle_standard_args)
CMakeLists.txt:30 (find_package)
Some nixos packages have extra dev outputs like for example debian packages. They are usually located under .dev . In mkDerivation they are chosen automatically. I don’t think nix-shell does the same.
Yes. Doing your development within nix-shell or nix develop is the best way to go, for several reasons:
If you move to a new computer, or need to onboard a contributor, or just need to document the build steps you never need to remember what packages need to be installed, or what version they were at the time, or what pkg-config tweak you made while debugging. All that information is in the shell expression, and hopefully lives with your project in version control.
you don’t pollute your main system’s search paths and environment variables with build hooks and CMAKE flags intended for this one project. This lets you work on multiple projects, or even just the same project on different major versions, at the same time without cross-contamination.
If you need to ask for help, someone in the nix community can use your shell expression and be up and debugging the problem with you in minutes. Lowering the barrier to collaborators is the best way to get free advice from people on the internet.
Ok, so I have a shell.nix in my project. But it seems to not pick up on custom themes in plasma or in qt5ct if I’m using a wm. I’d like to test the app in various themes to ensure it’ll look ok. Any idea what I’m missing?
But even removing all of those shellHook pieces I get the same result. I can always get it to build, but the themeing doesn’t apply properly. It can pick up parts. The view background and icons, but not the window background and such.
Right. But QML2_IMPORT_PATH is already set by setQtEnvironment. So replacing it with a custom value will just remove stuff.
wrapQtAppsHook populates QT_PLUGIN_PATH and QML2_IMPORT_PATH in qtWrapperArgs array with appropriate paths from inputs. You need to figure out which packages and environment variables are responsible for what you want to achieve. The answer can likely be found in Qt documentation or source code.
I’m not really familiar with the way that qt apps pick up themes, but I think it likely that you’ll need to add the theme packages to the nativeBuildInputs list.
Using nix-shell is going to try and isolate that shell environment as much as possible from your current system state, so it makes sense that when run within that shell your app won’t be able to pick up on system themes.
Unless you use nix-shell --pure, the parent environment will remain as a base for the generic builder. So unless some setup hook intentionally or accidentally overrides a relevant variable, that should not be the case.
I would look at contents of the theme packages you want to use. If it contains stuff mainly under /share subdirectory, it is likely being looked up in XDG_DATA_DIRS environment variable. If there is /lib it will likely need a different environment variable.
And with /lib there might be issues with binary compatibility between Qt from the shell and the theme.
yep, good catch. I usually use --pure mode and forgot that the normal mode doesn’t provide full isolation.
I still think that while nix-shell is extending environment variables like PATH, it could be overwriting others e.g. qt theme paths, QML2_IMPORT_PATH, etc.
I believe it’s still worth adding the plasma themes you want to test into the nix-shell definition.
Thanks for the idea, I’m sure gonna try it tomorrow. Had a couple days of other things going on. But maybe you can help me parse out the right way I should be doing this too. If nix-shell is technically the older way of doing this and nix develop is newer. What would I be needing to do in order to convert my shell.nix to work with nix develop?
I would recommend staying with nix-shell – nix develop requires buying into the Flakes experimental format, which will not fix your issue and only introduce more boilerplate, benefits of which you probably won’t be able to appreciate yet. Unless you really want to dive into latest and greatest experimental API that can change under you – in that case, dive right in.