multiple KDE sessions support (was [dbus] Re: Cmake update patch for dbus master)

[Ralf Habacker]

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