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

List:       kde-core-devel
Subject:    RE: Fwd: Re: libkio GUI (was Re:Changing library structure (examp
From:       David Faure <David.Faure () cramersystems ! com>
Date:       1999-12-13 16:06:31
[Download RAW message or body]

> Hi,
> 
> On Son, 12 Dez 1999, David Faure wrote:
> > On Sun, Dec 12, 1999 at 01:57:55PM +0000, Stephan Kulow wrote:
> > > David Faure wrote:
> > > > 
> > > > On Sun, Dec 12, 1999 at 01:32:39PM +0000, Stephan Kulow wrote:
> > > > > David Faure wrote:
> > > > > >
> > > > > > On Sun, Dec 12, 1999 at 12:55:39PM +0000, Stephan Kulow wrote:
> > > > > > > This daemon is no good idea - why not simply do a libkioui?
> > > > > > Because KIOJob is the central part of libkio and it needs
dialogs.
> > > > > >
> > > > > Yet :)
> > > > >
> > > > > OK, libkioui is perhaps the wrong name. How about libkiocore
> > > > > which offers the functionality without UI and libkio puts the
> > > > > dialogs on top of this?
> > > > 
> > > > Sounds good, but how does the app that just want a download with
> > > > the default dialogs do ?  e.g. when using KIONetAccess or KIOJob
> > > > to get a text file for kedit.
> > > > Does the app have to connect some signals/slots (since KIOJob can't
> > > > call the dialogs by itself in this design) ?
> > > > 
> > > why? KIOJob will be the full featured tool class it is now.
> > 
> > Ah ? What will be in libkiocore then ?
> > KServiceType, KMimeType, KService, KSycoca*  (with a few 
> KMessageBox removed) ?
> > (and of course KUserPaths, KTrader*, KUserProfile, no 
> problem for those)
> > 
> > Looks like you're going to have the same problem I had when 
> trying to split kio.
> > 
> > KService calls KAutoMount/KAutoUnMount, which calls KIOJob ...
> > and here you go, kiocore needs kioui :-)
> > 
> > But I'd be really glad if we could find a solution, though !
> > 
> > [ Perhaps this mount/unmount stuff could be moved out of 
> kservice and
> > into konqpopupmenu. Radical but works. ]
>    ^^^^^^^^^^^^^^^^^^^^^^
> 
> That looks like broken design for me.
> 
> Bye
> Torben

Sorry I meant into a class in libkonq, which currently would be only
used by konqpopupmenu. But then it turns out this is wrong anyway :
what if mounting takes ages, like NFS, or very slow cdrom, ...
The user needs feedback, and being able to cancel.
Whereever it is, it's not just a call to system().
I discussed this with Stephan and seeing that a bit of IPC was needed
for that as well, the choice remains being : keeping it in kio_file
(my suggestion), or using a pipe to a forked process (Stephan's suggestion).
To be refined after Krash I think.

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramersystems.com - Cramer Systems

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