KWallet problem for daemon process

Jason 'vanRijn' Kasper vr at movingparts.net
Mon Aug 20 01:56:42 BST 2007


On Sunday 19 August 2007, David Faure wrote:
> On Monday 20 August 2007, Jason 'vanRijn' Kasper wrote:
> > On Sunday 19 August 2007, David Faure wrote:
> > > On Saturday 18 August 2007, Jason 'vanRijn' Kasper wrote:
> > > > Hi George!!  =:)
> > > >
> > > > Can you point me to some kio code that does this?  I looked in a few
> > > > KIO directories, but nothing that I saw uses the Wallet...
> > >
> > > KIO talks to kpasswdserver which talks to kwallet.
> >
> > Hi David,
> >
> > kdelibs/kio/kio/slavebase.cpp -- this still uses windowId, gotten by
> > this:
> >
> > const long windowId = metaData("window-id").toLong();
>
> Sure. (so? I'm not sure what you deduce from this)

Heh.  I was just saying that at the end of the day, we still don't have a 
window available to use from kpilotDaemon.  =:)  I was thinking originally, 
when kpasswdserver was mentioned, that there'd be some tricky workaround for 
the problem of not having a window, but it looks like the "tricky workaround" 
is a way to get the window id of the window that's there without the slave 
having a direct relationship/handle to the window itself?  That is to say 
that it seems like these kio slaves are still called by a class/process that 
has a visible window that is used to pop up the Wallet prompt.

> > So, it sounds like our only choices are:
> >
> > 1) introduce a new top-screen window for kpilotDaemon while it's syncing
> > and use it
>
> Major GUI change I suppose... but why not, it might give a better user
> experience than unexpected popups (see below).

Yes, in the long run, we may do this... like gpilotd's popup progress window.  
I don't think we'll be able to pull this off anytime soon, though--we still 
have some pretty big fish to fry to get things working that should be.

> > 2) use 0 for the window id
> >
> > Sounds like the downside to #2 is that the password prompt from the
> > wallet won't pop up in the foreground?
>
> Focus-stealing prevention might do that, yes, if the user is typing at the
> same time. That might actually be good, no? The whole point of
> focus-stealing prevention is exactly that popups don't come up unexpectedly
> and steal focus from the current window...

Yes, that would be a good thing. =:)  

I think my original question is answered.  =:)  It's not that the Wallet 
subsystem was written to not allow non-GUI/daemon processes to use it (being 
that we can use 0 as the window id), but the problem is that if Wallet needs 
to prompt the user, it won't be able to pop its dialog over the top of 
anything meaningful to the user (because there is no visible parent window 
for Wallet to use).

Thanks David and George for your help and patience.  =:)


-- 
 -[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
 -[ KDE PIM Developer         //  http://www.kde.org  ]-
 -[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-




More information about the kde-core-devel mailing list