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

[Ralf Habacker]

Ralf Habacker schrieb:
> 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.
>
>   
There are more issues:

Say I have dbus-daemon and klauncher started from release installation. 
Then I enter the debug installation and start khelpcenter, which will 
raise up and will be registered in dbus as org.kde.khelpcenter.
When I now start an application in release installation and enter the 
help the debug khelpcenter will be opened and depending on the installed 
packages it may do not contain the expected content because of the 
different installation. There is NO way to open release khelpcenter 
neither through the help button nor from the command line because of the 
dbus registration of debug khelpcenter.

Ralf








> Ralf
>
>
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
>