Am 11.11.2011 17:01, schrieb Alexander Neundorf:
On Friday 11 November 2011, Ralf Habacker wrote:
Hi,
in the past the KDE on Windows port has been faced with install path
related issues caused by the fact that in opposite to unix/linx the end
user install location differs from the build time install location.
While several issue has been solved in the past, others may be still
present.
Patrick von Reth for example reported shortly ago that there are
problems with dbus service files generated by the build system. The
generated install location points to the build install location, which
will not work on end users workstation.
A few days ago Alexander Neundorf, the maintainer of the KDE
buildsystem, asked me if there are still such problems, so if anyone
know about open install location related problems, please report.
- On the kdepim meeting this year in osnabrück Andre Heinecke and I
recognized a home dir problem between independent KDE installations on
windows like kdepim setup installer and community distribution.
Currently independent installations depends on the same home dir, which
may produce unwanted interferences and/or conflicts
- in ksyscoca database (affects system settings modules)
- application settings
- There is a kde-runtime windows platform config module, which sets
install root depending registry keys
https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/master/show/platforms/win/config
- There is a kde-runtime system context menu module, which sets insstall
root depending registry keys
https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/master/show/platforms/win/contextmenu.
Currently people can use environment variables to define a different
home dir, but this do not help gui orientated os like windows. A
solution will be to have a kind of use-install-root-related-home-dir.
This would be extremly helpfull with usb-stick installations, where the
home dir(s) are also on the usb stick.
Please not only about the places where they are still open, but also those
places where it has been already fixed/worked around/hacked to make it work
somehow.
From my memory these are:
- dbus daemon determines the location of config files from the location
of the dbus executable
http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-win.c#n3182
- dbus provides an install root limited session bus
http://dbus.freedesktop.org/doc/dbus-specification.html#meta-transports-autolaunch
- dbus is going to determine the location of executables in dbus service
files from the location of the dbus-daemon executable (use
BIN_INSTALL_DIR as service executable path, dbus patch required)
- qt determines several dirs base from a dedicated qt.conf relative to
the install root
https://projects.kde.org/projects/kdesupport/emerge/repository/revisions/master
/entry/portage/libs/qt/qt.conf
- kde4-config determine the install root by the location of the kdecore
shared library -
https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kdecore/kernel/kkernel_win.cpp#L97
I'm not sure if this is all.
Regards
Ralf
_______________________________________________
Kde-windows mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-windows
