Ralf Habacker schrieb: > Romain Pokrzywka schrieb: > >> (nb: Forking from the thread on DBus, since it's more of a KDEWin issue than >> a dbus one) >> >> On Monday 15 February 2010 03:12:50 Ralf Habacker wrote: >> >> >>> Ralf Habacker schrieb: >>> >>> >> [...] >> >> >>> A possible implementation could extend the autolaunch bus address type >>> with a scope attribute >>> >>> autolaunch:scope=<value> >>> >>> where value could be the predefined term 'install-path'. If the server >>> find such a session bus address it will listen on a free tcp port and >>> publish the recent session bus address in a shared memory segment, which >>> is postfixed by a hash value of the libdbus installation root. Every >>> client which uses the same session bus address would be able to connect >>> the related daemon. >>> >>> There is also an additional feature available by using this scope >>> attribute. Any non empty value except the above mentioned 'install-path' >>> value will create a specific namespace and could be used to create >>> specialized dbus session buses. >>> >>> This feature will be enabled with a (cmake) configure option named >>> DBUS_USE_LIMITED_SESSION_DEFAULT_ADDRESS. >>> >>> Any comments or addons ? >>> >>> >> (nb: context: we are discussing options for having multiple KDE-windows >> releases running side by side, with a dbus >> session bus for each and with KDE apps from each release talking to their >> matching daemon) >> >> I'm not sure if this is the right place where the issue should be addressed, >> at least in the KDE-Windows context. >> >> Regarding sessions started from a kdeenv.bat console, the problem is solved: >> adding a DBUS_SESSION_ADDRESS env var to >> kdesettings.bat is trivial and does exactly what we want (whoever needs it >> can adjust it for each concurrent session >> bus). >> >> For sessions not started from a console, such as releases from the >> installer, I'm not sure if it's really a use-case >> worth being considered. >> > This is the default case on windows. Every KDE package installed by any > type of any single click or other installer will probably have start > menu entries and the related applications will *not* be started from a > console. With your statement above you say that there is only one KDE > package startable from the start menu. Any additional packages should be > started from the console and is not allowed to have start menu entries. > Makes this really sense ? > > BTW: For those who do not know already: Creating start menu entries is a > build in kdebase runtime feature since about two years - see > http://websvn.kde.org/trunk/KDE/kdebase/runtime/platforms/win/kwinstartmenu/readme.txt?view=markup > > for more informations. > > >> Will users often have multiple versions installed side by side ? >> > yes. For the kde on windows community release: there are three branches. > stable,unstable and nightly. They can be installed and updated > independently from each other and they are uses all three. The only > issue currently is the shared dbus session bus which makes it impossible > to make sure, that applications reachable over dbus are from the same > installation path.[1] > > In the kdepim enterprise world I guess there will be also at lest two > binary package branches, stable packages and unstable/development > packages. If you have only one session bus you will have also troubles > to distinct applications reachable over dbus. You cannot be sure that > applications from the stable package will use applications reachable > from dbus from the stable installations. This results into a support > night mare isn't it ? > > here is a detailed example:
Assume you start umbrello release - this will call - from the release installation - kdeinit4, which will start dbus-daemon, then klauncher and kded. Then on request klauncher will start kioslaves from the release installation. Then on umbrello debug, unstable or nightly start from a separate installation (a separate installation is required on windows) - it will call - from the debug installation - kdeinit4, which detects that release dbus-daemon is already running, a klauncher is already registrated and kded too. Then on request debug klauncher will start release kioslaves and any other requested application from release installations - which is *not* intended for a debug, unstable or nightly installation. Ralf _______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
