[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: doubt about kioslave
From:       Luca Ferrari <fluca1978 () infinito ! it>
Date:       2012-06-12 8:07:28
Message-ID: CAKoxK+6-Ou946Bd3VrFxBEh8vDfichJ1xd1v0ESjr9M+ce3MOQ () mail ! gmail ! com
[Download RAW message or body]

Thanks for the explaination. As far as I understand a kded module is
required to handle per-user configuration to share with all running
slaves, but is there any tutorial or sample I can start studying from?
I cannot find one and the kded documentation is not so clear to me.

Thanks,
Luca

On Mon, Jun 11, 2012 at 8:10 PM, Albert Astals Cid <aacid@kde.org> wrote:
> El Dilluns, 11 de juny de 2012, a les 17:59:44, Luca Ferrari va escriure:
>> Hi all,
>> I'm making my first kioslave and I've got a doubt, as already posted
>> here http://forum.kde.org/viewtopic.php?f=43&t=102547.
>> My protocol has the lines:
>>
>> [Protocol]
>> exec=kio_rolefs
>> protocol=rolefs
>>
>> and my kdemain is as follows:
>>
>> extern "C" int KDE_EXPORT kdemain( int argc, char **argv )
>> {
>>   kDebug(RoleFSDebugArea()) << "[kdemain] starting";
>>   KComponentData instance( "kio_rolefs" );
>>
>>
>>
>>   kDebug(RoleFSDebugArea()) << "kdemain is creating a slave...";
>>   RoleFSKIOSlave slave( "Hello","Slave", instance, argv[2], argv[3] );
>>   kDebug(RoleFSDebugArea()) << "staring the dispatch loop";
>>   slave.dispatchLoop();
>>   kDebug(RoleFSDebugArea()) << "kdemain] ending";
>>   return 0;
>> }
>>
>>
>> So it should do nothing very special here. However, when I open
>> dolphin (a single window) and point it to the rolefs:/// path I see in
>> the ~/.xsession-errors log file the following messages:
>>
>> unnamed app(9078)/[RoleFS debug] kdemain: [kdemain] starting
>> kio_rolefs(9078)/[RoleFS debug] kdemain: kdemain is creating a slave...
>> kio_rolefs(9078)/[RoleFS debug] kdemain: staring the dispatch loop
>> unnamed app(9084)/[RoleFS debug] kdemain: [kdemain] starting
>> kio_rolefs(9084)/[RoleFS debug] kdemain: kdemain is creating a slave...
>> kio_rolefs(9084)/[RoleFS debug] kdemain: staring the dispatch loop
>> unnamed app(9087)/[RoleFS debug] kdemain: [kdemain] starting
>> kio_rolefs(9087)/[RoleFS debug] kdemain: kdemain is creating a slave...
>> unnamed app(9088)/[RoleFS debug] kdemain: [kdemain] starting
>> kio_rolefs(9088)/[RoleFS debug] kdemain: kdemain is creating a slave...
>> kio_rolefs(9087)/[RoleFS debug] kdemain: staring the dispatch loop
>> unnamed app(9089)/[RoleFS debug] kdemain: [kdemain] starting
>> kio_rolefs(9089)/[RoleFS debug] kdemain: kdemain is creating a slave...
>> kio_rolefs(9089)/[RoleFS debug] kdemain: staring the dispatch loop
>> kio_rolefs(9088)/[RoleFS debug] kdemain: staring the dispatch loop
>> unnamed app(9090)/[RoleFS debug] kdemain: [kdemain] starting
>> kio_rolefs(9090)/[RoleFS debug] kdemain: kdemain is creating a slave...
>> kio_rolefs(9090)/[RoleFS debug] kdemain: staring the dispatch loop
>>
>> therefore there are processes 9078, 9084, 9087, 9088, 9089 and 9090
>> for a total of 6 kioslaves running at the same time. The rolefs:///
>> root path displays 3 icons, one of which contains 4 other elements.
>> Besides this, I'd like to know when kioslave are created and how is it
>> possible to handle a "shared" state so that if the user opens two file
>> manager views the slaves are accessing the same underlying values
>> (beside haveing to re-read the configuration).
>
> kioslaves are by definition stateless, i.e. you can't assume anything about a
> running instance being reused or a new one being spawned, etc. If you need to
> keep state I think the common solution is to have a kded that the slave
> communicates with. Also having a maxInstances of 1 might help.
>
> You can have a look at
> http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves to
> learn how to debug your slave.
>
> Cheers,
>  Albert
>
>>
>> Thanks,
>> Luca
>>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>> >> <<
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]