Cmake update patch for dbus master

Ralf Habacker ralf.habacker at freenet.de
Tue Feb 16 01:17:23 PST 2010


Thiago Macieira schrieb:
> Em Terça-feira 16. Fevereiro 2010, às 08.50.11, Ralf Habacker escreveu:
>   
>> Romain Pokrzywka schrieb:
>>     
>>> On Tuesday 09 February 2010 06:58:53 Thiago Macieira wrote:
>>>       
>>>> I'd say the answer should be "Use the same technique as on Unix"
>>>>
>>>> If you require different busses, you just set a different environment
>>>> variable (DBUS_SESSION_BUS_ADDRESS). It will be inherited by all
>>>> processes in that session.
>>>>         
>> This will not work on windows. Applications are started from the start
>> menu - the start menu is managed by the explorer, which is one process.
>> Setting an environment variable in the explorer will force any
>> applications started from the startmenu to use the same session bus.
>>     
>
> That is not a problem.
>
> It's exactly what I said before: It's the same as Unix.
>
> If you start a D-Bus app without the environment set, it will use the 
> autolaunchable bus, found by whatever means the platform uses. And, yes, it 
> will be unique and will be the same for all apps.
>
> That means both debug and release apps will talk to the same bus and will talk 
> to each other.
>
> That's a good thing and that should be the objective.
>   

>>> Still, Ralph is talking about another use case, where we don't have a
>>> console-provided environment.
>>>       
>> yes
>>     
>
> See above.
>
>   
>>>> In theory, it would be possible to run two sets of those applications on
>>>> the same computer, by the same user, if they were in separate buses. But
>>>> at least on Unix, kdeinit4 also creates a socket which is keyed to the
>>>> X display, so it wouldn't work -- on Windows, it may.
>>>>         
>>> It does. That's why the idea of having multiple dbus-daemons running and
>>> apps talking to the right one is tempting. However, I don't think
>>> ensuring the apps talk to the right daemon is really the responsibility
>>> of dbus, so I think I agree with you below.
>>>       
>> dbus lacks some support to be able to handle this on windows.
>>     
>
> The right daemon is the one that you configure with the environment variable.
>
> If you don't configure, it's the default, autolaunchable one. Just like on 
> Unix.
>
>   
>> The default case on windows is that applications are started from the
>> start menu.
>> If there are separate KDE installations, how should it be able to select
>> different dbus session busses ?
>> The arguments I heard until now do not apply.
>>     
>
> They should NOT select different busses.
>
> Apps should ALL use the same bus.
>   
When I follow your arguments then there are still the following issues:
- the klauncher issue 
http://mail.kde.org/pipermail/kde-windows/2010-February/004663.html for 
which i do not see any solution without having different session bus 
support (requiring command line console is not a choice in the windows 
gui world.)
- on windows the session bus isn't started at user session setup, which 
means in fact that the dbus-daemon located in the installation path of 
the first started application with dbus support will provide the user 
session bus - is this intended ?

BTW: In case someone is in trouble because of who will implement this 
suggested feature - i have a 95% completed patch for the suggested 
different session bus feature, there is only the test case missing.

Regards
 Ralf

>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>   



More information about the dbus mailing list