remove QtGui dependence of kdecore

[Ralf Habacker]

Thiago Macieira schrieb:
> Simon Hausmann wrote:
>   
>>> On another topic, do you think it make sens to split kio in kio_core
>>> and kio_ui ?   this would allow to use kioslave in console
>>> application.
>>>       
>> How useful is that, is it worth it?
>>
>> It affects 99% of all KDE applications, they have to link against /yet/
>> another library (not helping with startup time and the generated code
>> that calls between kio_ui and _core), just for this one or two
>> applications that don't want to link against gui?
>>     
>
> Discussing this with Kévin yesterday (Olivier had unfortunately just 
> timed-out in IRC), we actually came to a better wording:
>
> Continue to move non-GUI code out of KIO into kdecore, like it was done 
> with the KIO::Job split into KJob. This should be done where it's 
> needed -- and Kévin has use-cases.
>   
Perhaps this isssue fits partial into this thread:

While porting the kdecore/network code and kioslaves to windows, I 
recognized that the class KIO connection implements network read/write 
stuff already implemented in classes of kdecore/network. I understand 
that KIO connection uses a command based read/write api which is 
different from the related kdecore/network class and that this may be 
the reason that this class could not be in kdecore but could they not 
use the kdecore/network provided platform independent functions ?  

BTW: This belongs also to the used select() function.

It was discussed in this mailing list if it would be able to use threads 
for kio-slaves. I think having a common base of a communication api (in 
kdecore/network ?), would makes makes porting kio slaves to another 
communication procotol like named pipe or shared memory easier.

Ralf