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 ? > If so, do they really want them to be isolated, yes, see above > or rather want them to appear as one same session ? not yet > What about drawing a line by saying: if you need to have multiple versions of > KDE running simultaneously, please run > them from a console (something like kdeenv.bat, but only for runtime > settings) ? > This is not practicable and will not be liked by users as they expect to start applications from the start menu. Ralf _______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
