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

List:       kde-commits
Subject:    Re: KDE/kdelibs/kdeui/windowmanagement
From:       Romain Pokrzywka <romain () kdab ! net>
Date:       2009-07-15 10:37:27
Message-ID: 200907151237.27610.romain () kdab ! net
[Download RAW message or body]

Hi,

Sorry for the late reply.
Basically, on Win32 a window cannot come to the foreground (e.g by calling raise() \
and activate() ) if it's not in the  currently active process. For example, imagine \
you have some IM chat window opened, but you've switched to Firefox to  check some \
website. While you're browsing, a message arrives and the chat window calls raise() \
to be brought to the  front. While this will probably work on Unix, on Win32 it \
won't, and the only thing you'll get is a flashing entry in  the taskbar.

But sometimes you really want a window from another process to be allowed to come to \
the foreground and become the  active window, typically because you know it, so the \
Win32 API has a function called SetAllowForegroundWindow() which  temporarily allows \
a window from another process to be raised and activated. One typical case (which was \
why I've added  it in the first place) is for the kwallet password prompt : let's say \
we're in Kontact (so it's the active process), and  it asks for a password stored in \
kwallet. This is done through a dbus call from kontact to kwalletd. If the wallet \
isn't  opened, kwalletd pops up the prompt to enter the password to open the wallet. \
However, this prompt cannot be brought to  the foreground since kontact is currently \
the active process, and not kwalletd. So the prompt is shown, but only in the  \
background and not activated, which makes it hard to notice (iirc. the taskbar \
doesn't even flash then). But by calling  allowExternalProcessWindowActivation() from \
kontact just before making the dbus call, then the prompt is correctly shown  on top \
of kontact and activated, since we allowed the kwalletd process to steal the focus. 

Note that the other process doesn't know about this allowance, it just calls raise() \
and activate() on its windows. If  SetAllowForegroundWindow() has been called, then \
the window will be brought to the front just fine, otherwise it won't  and you'll \
just get the flashing taskbar entry for that window.

Finally, the function only has an effect if the process that calls it is the active \
process, obviously.

I hope it's a bit clearer now. Please tell me if I should change the docs, or if you \
think there's a better naming for  the function. maybe \
allowAnotherProcessToStealFocus() ?

Cheers

-- 
Romain Pokrzywka | romain@kdab.net | Software engineer & Qt trainer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
On Monday 13 July 2009 13:50:52 Oswald Buddenhagen wrote:
> On Sun, Jul 12, 2009 at 11:54:11PM +0000, Romain Pokrzywka wrote:
> > SVN commit 995565 by pokrzywka:
> > 
> > --- trunk/KDE/kdelibs/kdeui/windowmanagement/kwindowsystem.h
> > #995564:995565 +     * Allows a window from another process to raise and
> > activate itself. [...]
> 
> after reading that doc i still don't know who is requesting what from
> whom ...


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