From ludvigsen on IRC last night, it appears that `kritarunner.exe` is built using the windows subsystem, which causes some significant usability issues: - When run from cmd.exe (and possibly PowerShell), the command returns immediately, instead of waiting for the subprocess to exit. - qDebug output get printed via OutputDebugString which can only be viewed using DebuvView (or if the parent process is reading the stdout/stderr pipes). This would be a huge obstacle to users without prior knowledge on this. **Proposed Solution:** Build the kritarunner target to use the console subsystem. ECM has this function to mark it as such: https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/master/modules/ECMMarkNonGuiExecutable.cmake Potential issues: If a user had been relying on the existing behaviour this will be a breaking change. Though I don't think it makes sense for anyone to rely on this broken behaviour. **Alternative Solution:** It is possible to build a separate `kritarunner.com` to be a console application, so when someone runs `kritarunner` from cmd.exe it will start `kritarunner.com` instead of `kritarunner.exe` and get proper console output. For example, Inkscape on Windows use this approach.
I'll confirm this, given it's known the situation should change.
Git commit f63e9535e27ba8efe73d6bb26164b0587cc09d9f by Alvin Wong. Committed on 18/05/2021 at 07:33. Pushed by dkazakov into branch 'master'. Add console versions of krita.com and kritarunner.com M +30 -1 krita/CMakeLists.txt M +10 -2 krita/main.cc A +14 -0 krita/windows_stub_main.cpp [License: GPL(v3.0+)] M +4 -0 packaging/windows/package-complete.cmd M +33 -14 plugins/extensions/pykrita/kritarunner/CMakeLists.txt https://invent.kde.org/graphics/krita/commit/f63e9535e27ba8efe73d6bb26164b0587cc09d9f