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

List:       kde-devel
Subject:    Re: Getting a string from the user in a KIOSlave
From:       Shaun Jackman <sjackman () home ! com>
Date:       2001-11-17 1:21:24
[Download RAW message or body]

On Fri November 16, 2001 10h35, David Faure wrote:
> On Friday 16 November 2001 16:42, Shaun Jackman wrote:
> > This seems to defeat the modularity of a KIO::Slave. If reading this
[clip]
> > can give me a better solution.
> When I say "in the application", it means, in the process of the
> application. This doesn't necessarily mean duplicating code, one can use
> the functions in the libraries - as we do currently for everything else
> that happens "in the app" like the password-dialog and the kio_uiserver's
> message boxes.
My KIO::Slave is distributed seperately from KDE (it's not quite stable yet); 
you can find it on SourceForge. In this case, the app is Konqueror. Is a 
patch to Konqueror needed to make my pet project work? This doesn't seem very 
clean. I like the KIO framework because I can distribute a toy KIO as a 
shared lib and nothing in the main KDE branch has to be affected.

> > I'm writing a KIO::Slave for the Nomad Jukebox (an mp3 player with a 6
[clip]
> > but it's about as useful as dirt. Any ideas?
> Yes, what you're missing is an extension to SlaveBase::messageBox
> that lets the slave pop up a message box (in kio_uiserver's process, via
> the application) that contains a lineedit. The current message boxes
> are simple yes/no/cancel and such. Feel free to post a patch that extends
> the functionality of SlaveBase::messageBox (or adds a new method like
> SlaveBase::getInputText), with the necessary forwards to kio_uiserver
> and the actual implementation in kio_uiserver.
I'm not all that familiar with the UI components of KDE. Since Qt already 
implements a useful interface QInputDialog, do I simply have to wrap this? Or 
does it have to be reimplemented?

Thanks,
Shaun
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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