remove QtGui dependence of kdecore

Ralf Habacker ralf.habacker at
Wed Jan 3 18:43:22 GMT 2007

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.


More information about the kde-core-devel mailing list