Bug 319247

Summary:	KTouch starts with an empty window on Windows
Product:	[Applications] ktouch	Reporter:	Lasse Liehu <lasse.liehu>
Component:	general	Assignee:	Sebastian Gottfried <sebastian.gottfried>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	adaptee, kde-windows, ps_ml
Priority:	NOR
Version:	2.0.0
Target Milestone:	---
Platform:	Microsoft Windows
OS:	Microsoft Windows
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Lasse Liehu 2013-05-03 00:18:51 UTC

Installed from "stable 4.10.2" release using KDE Installer 1.0.0 to the default location.

The following was printed to stdout/stderr/whatever (found with WinDbg):
file:///c:/programdata/kde/share/apps/ktouch/qml/main.qml: File name case mismatch

The actual path was "C:\ProgramData\KDE\share\apps\ktouch\qml\main.qml".

Reproducible: Always

Steps to Reproduce:
Starting KTouch from the shortcut created by KDE Installer or directly clicking the exe from Windows Explorer.
Actual Results:  
The window of KTouch is empty and nothing can be done except closing it.

Expected Results:  
KTouch starts fine.

Comment 1 Sebastian Gottfried 2013-05-03 08:22:40 UTC

Since the whole user interface of KTouch is realized with QML it looks like the initialization of the QML view failed ('main.qml' is, as the name suggests, the central UI component pulling in all the other bits). This fits nicely with the console output you've have posted, it seems that the QML engine cares about capitalization of the used paths even on Windows. 

The thing is KTouch obtains the path to 'main.qml' the usual way, that is via `KGlobal::dirs()->findResource("appdata", "qml/main.qml")`. So if my theory is correct the issue is most likely a kdelibs bug.

Since I don't have an Windows development environment around I can't confirm this myself in the near future. I would be very grateful if someone from the KDE on Windows team would find some time to investigate what's up with KStandardDirs::findResource on Windows.

Comment 2 Patrick Spendrin 2013-05-03 08:37:37 UTC

Could you specify the compiler? I can see the user interface on mingw64 with win7 64bit.

Comment 3 Lasse Liehu 2013-05-03 08:51:32 UTC

The compiler is MSVC 2010 32bit.

Comment 4 Patrick Spendrin 2013-05-03 09:09:29 UTC

Ok, this should be fixed now, it works for me, it probably is due to a broken libbzip2 package at the beginning.

Comment 5 Sebastian Gottfried 2013-05-03 09:19:20 UTC

@Patrick Thanks for the near-instant support. The KDE community doesn't fail to amaze me. It would have taken me hours to get to the bottom of this.

Comment 6 Patrick Spendrin 2013-05-03 12:39:18 UTC

ok, sorry, I was to early, I can reproduce this now with the x64 compiler installation. My guess is that this is due to the spaces in the installation path. I will try to look into that soon.

Comment 7 Jekyll Wu 2013-06-24 14:55:14 UTC

I'm also using MSVC 2010 32bit installation, and had the same problem last month, but can't reproduce any more after recent updating. Has this problem been fixed ?

Comment 8 Lasse Liehu 2013-06-24 16:52:01 UTC

Now using MSVC 2010 32bit it's working for me, too, but using MinGW 64bit it still doesn't work.

Comment 9 Patrick Spendrin 2013-06-25 00:01:35 UTC

Well, afair I haven't done anything to fix this yet.

Comment 10 Patrick Spendrin 2013-08-01 09:22:00 UTC

Ok, found the problem, this happens only with mingw binaries. to work around this problem, rename all dlls under lib\kde4\imports from lib....dll to ....dll. The problem is that the qml plugins are build as shared libraries but should be plugins (which do not have a lib prefix). This will be fixed for the next release.

Comment 11 Sebastian Gottfried 2019-10-22 18:32:02 UTC

I am closing this bug as it is really old and is no longer relevant. There is no Windows version of KTouch anymore.