remove QtGui dependence of kdecore
ralf.habacker at freenet.de
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
>> 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