D-Bus problem

[Ralf Habacker]

Andreas Pakulat schrieb:
> On 17.05.07 11:59:15, Ralf Habacker wrote:
>   
>> Andreas Pakulat schrieb:
>>     
>>> On 15.05.07 00:44:12, Ralf Habacker wrote:
>>> talk to klauncher: The name org.kde.klauncher was not provided by any
>>> .service files".
>>>
>>> After moving klauncher from lib/kde4/libexec to bin/ that one is gone (I
>>> guess on windows there shouldn't be anything installed into libexec??)
>>>   
>>>       
>> yes
>>     
>
> Ok, I guess I'll do that tomorrow unless somebody else is faster (that
> == fixing CMakeLists.txt to not install anything into libexec on win32)
>
>   
>>> and I get the same message as you, saying that a file slave is created.
>>> One thing that is weird is that the path is something like
>>>
>>> file:///C:/Dokument                     4096nd
>>> 0.000000E+000instellungen/Andreas
>>>
>>>   
>>>       
>> There may be KUrl/Qurl  fixes required see 
>> http://lists.kde.org/?l=kde-windows&m=116663586908938&w=2, but this 
>> issues should be fixed in the second step. More important is that the 
>> socket communications works.
>>     
>
> Good that I see that now. We've got a couple of places in KDevelop where
> we use path() instead of toLocalFile. I'll fix those right now.
>
>   
>>> I'll now try to find the base classes of
>>> kio_file slave and check wether I find any changes in that.
>>>   
>>>       
>> See kio\kio\slavebase.cpp. On unix the master opens a unix domain socket 
>> to which the client connects. On windows the socket should be tcp and 
>> the message above indicates that the client could not connect to the 
>> socket the master has opened.
>>     
>
> Hmm, there has been a change recently to tcp stuff in there, the int
> that was used for the port was changed to a qint64 (iirc) and is not
> global to the function it is used in (don't have the source line at
> hand). I reverted that change, but didn't get anywhere...
>
>   
>>> If that doesn't bring anything, how do I debug kio slaves under win32?
>>>   
>>>       
>> The problem is that debugging kioslaves is very dynamic because of 
>> process starting and socket connection timeouts.
>>     
>
> On Unix and KDE3 one could attach a gdb if you're fast enough. First you
> had to restart kded with an env var set then it would always produce the
> pid of the kioslave on stderr when a new kioslave is created. I guess
> this doesn't work on Windows.
>   
Which var is it ? I added pid printing to kdebug unconditional to be 
able to see the pid of any process so the kioslave pid is printed by the 
klauncher console windows.
Additional the last kDebug patch should output stderr to the parent 
console windows too.

>   
>> BTW: I used kioslavetest to check the kio communication.
>>     
>
> Thats probably easier than using KDevelop to test kio :)
>
>   
yes, katetest is also a good kioslave tester.