Talk:Installing third party softwares in terminal/Build/KDE4/Windows: Difference between revisions

From KDE TechBase
No edit summary
m (moved Talk:Getting Started/Build/KDE4/Windows to Talk:Installing third party softwares in terminal/Build/KDE4/Windows: I want to know how to install a 3rd party software , which doesn't have 1-click install. eg. i downloaded pidgin and extract)
 
(18 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{improve}}
==KDE-Windows Meeting: Notes==
==KDE-Windows Meeting: Notes==
Started: [[User:Jstaniek|jstaniek]] 11:40, 15 September 2007 (CEST)
Started: [[User:Jstaniek|jstaniek]] 11:40, 15 September 2007 (CEST)


Line 7: Line 8:
#*this makes mirroring possible
#*this makes mirroring possible
#having two or more main directories on the server: one for current stable release, one for 'unstable/testing' one
#having two or more main directories on the server: one for current stable release, one for 'unstable/testing' one
#*we need unstable releases to get people test software early and often and on Windows
#*'unstable' is the term for base system (kdewin32, kdelibs, kdebase); note that in turn, unstable _applications_ could be installed in a stable base system as it's the case on Linux
#development installation requires tools having own installers
#development installation requires tools having own installers
#*ideally this should not be the case for end-user installation, otherwise updating would be hard (user would be forced to uninstall prev. version of an external app and install a new one in the same place...)
#*ideally this should not be the case for end-user installation, otherwise updating would be hard (user would be forced to uninstall prev. version of an external app and install a new one in the same place...)
#We need someone using Vista on daily basis to test kdeinstaller. Until then Vista is not supported?
#USB memory sticks/CDs: it would be possible to run kde apps/infrastructure installed on the stick/CD in two ways:
##If the user's machine already contains KDE 4 runtime installed, it could be reused to run apps from the stick, and settings placed on the host conuter could be reused
##If the user's computer contains no KDE-related stuff at all, default settings and .kde directory is used
#*In either case the default user expectation is that after plugging off the stick, no settings or files remain on the machine's filesystem <-really like that???
#format of the kde mirrors:
#*TODO
#Insert compiler name into package and manifest file name (msvc, gcc)
#snapshot releases with debugging information
#*New developers may want to get the core libraries without a need for compilation from scratch, while still being able to step deeply into the its source code while debugging. This helps to enter into the project faster by fixing bugs, discovering structure of a given source code or extending features.
#*Could we have release versions with debug information? On msvc, this could help to achieve the goal mentioned in the above point while it is still possible to link release binaries with and without debug information.
#dbus for win32 is working mostly for recent kde applications, although there are some issues:
#*A service registered in dbus is not removed in case the related application crashes. This was detected with klauncher on msvc.
#*if dbus-daemon is killed, the related tcp port is blocked for reusage for some time and prevents that the dbus-daemon can be started again. The solution is documented in http://support.microsoft.com/?scid=kb%3Ben-us%3B177074&x=7&y=11
#*Efforts to implement win32 named pipe transport protocol were canceled because its need refactoring of the internal dbus api which was to much work yet.
#*There is a bug in dbus which prevents to list anonymous connections. This behavior can be verified with qdbusviewer.
#*There are some efforts required to merge the windows port into the dbus cvs, especialy refactoring the internal api. TODO: more details 
# win32 issues with the cmake build system (TODO: list the issues)
# install system topics:
#* it is planned to evaluate the microsoft windows installer for releasing kde windows application.
#* if msi is not usable the kdewin-installer should be extended with the following features:
#**update function
#**simplified end user interface
#**integrity checks (md5 package and file checks) 
#**cd/dvd/usb stick installation
# missing or not working parts in kdelibs
#* phonon needs a win32 implementation maybe using directx with uses a COM interface
#* kioslaves are only working partially
# kde application state
#* kate - '@' could not be typed in
#* konqueror - crashes
#* dolphin - error messages with could not display root and home dir, problems to contact nepomukdaemon
#* umbrello - writing and printing does not work
#* ...
#compiler tools chain issues
#* loading kde applications into gdb needs a long time to load and start when libraries are compiled with debug symbols. This makes it hard to debug.
#* There are problems mixing msvc debug and release libraries resulting in runtime errors. One problem seems to be that the FILE structure differs between debug and release libraries. It has to be checked if there are workarounds for all developers.
=== KDE on Windows can be called the first official KDE-own distribution ===

Latest revision as of 02:09, 2 February 2011

Warning
This section needs improvements: Please help us to

cleanup confusing sections and fix sections which contain a todo


KDE-Windows Meeting: Notes

Started: jstaniek 11:40, 15 September 2007 (CEST)

Topics:

  1. reducing distribution of the file by keeping a snapshot of files on our server(s)
    • this makes mirroring possible
  2. having two or more main directories on the server: one for current stable release, one for 'unstable/testing' one
    • we need unstable releases to get people test software early and often and on Windows
    • 'unstable' is the term for base system (kdewin32, kdelibs, kdebase); note that in turn, unstable _applications_ could be installed in a stable base system as it's the case on Linux
  3. development installation requires tools having own installers
    • ideally this should not be the case for end-user installation, otherwise updating would be hard (user would be forced to uninstall prev. version of an external app and install a new one in the same place...)
  4. We need someone using Vista on daily basis to test kdeinstaller. Until then Vista is not supported?
  5. USB memory sticks/CDs: it would be possible to run kde apps/infrastructure installed on the stick/CD in two ways:
    1. If the user's machine already contains KDE 4 runtime installed, it could be reused to run apps from the stick, and settings placed on the host conuter could be reused
    2. If the user's computer contains no KDE-related stuff at all, default settings and .kde directory is used
    • In either case the default user expectation is that after plugging off the stick, no settings or files remain on the machine's filesystem <-really like that???
  6. format of the kde mirrors:
    • TODO
  7. Insert compiler name into package and manifest file name (msvc, gcc)
  8. snapshot releases with debugging information
    • New developers may want to get the core libraries without a need for compilation from scratch, while still being able to step deeply into the its source code while debugging. This helps to enter into the project faster by fixing bugs, discovering structure of a given source code or extending features.
    • Could we have release versions with debug information? On msvc, this could help to achieve the goal mentioned in the above point while it is still possible to link release binaries with and without debug information.
  9. dbus for win32 is working mostly for recent kde applications, although there are some issues:
    • A service registered in dbus is not removed in case the related application crashes. This was detected with klauncher on msvc.
    • if dbus-daemon is killed, the related tcp port is blocked for reusage for some time and prevents that the dbus-daemon can be started again. The solution is documented in http://support.microsoft.com/?scid=kb%3Ben-us%3B177074&x=7&y=11
    • Efforts to implement win32 named pipe transport protocol were canceled because its need refactoring of the internal dbus api which was to much work yet.
    • There is a bug in dbus which prevents to list anonymous connections. This behavior can be verified with qdbusviewer.
    • There are some efforts required to merge the windows port into the dbus cvs, especialy refactoring the internal api. TODO: more details
  10. win32 issues with the cmake build system (TODO: list the issues)
  11. install system topics:
    • it is planned to evaluate the microsoft windows installer for releasing kde windows application.
    • if msi is not usable the kdewin-installer should be extended with the following features:
      • update function
      • simplified end user interface
      • integrity checks (md5 package and file checks)
      • cd/dvd/usb stick installation
  12. missing or not working parts in kdelibs
    • phonon needs a win32 implementation maybe using directx with uses a COM interface
    • kioslaves are only working partially
  13. kde application state
    • kate - '@' could not be typed in
    • konqueror - crashes
    • dolphin - error messages with could not display root and home dir, problems to contact nepomukdaemon
    • umbrello - writing and printing does not work
    • ...
  14. compiler tools chain issues
    • loading kde applications into gdb needs a long time to load and start when libraries are compiled with debug symbols. This makes it hard to debug.
    • There are problems mixing msvc debug and release libraries resulting in runtime errors. One problem seems to be that the FILE structure differs between debug and release libraries. It has to be checked if there are workarounds for all developers.



KDE on Windows can be called the first official KDE-own distribution