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

List:       kwin
Subject:    Re: Donating the input focus to another application
From:       "Michael T" <raselmsh () hotmail ! com>
Date:       2007-05-14 15:25:44
Message-ID: BAY132-F1992365393F588AB7696C2D03E0 () phx ! gbl
[Download RAW message or body]

Thanks for the helpful and informative reply!

Regards,

Michael

>From: Lubos Lunak <>
>On Monday 14 of May 2007, Michael T wrote:
> > Hello All,
> >
> > I have the following question: is there an "official" way, which will 
>work
> > with KWin and with Metacity, of "donating" the input focus to a window
> > belonging to another process and at the same time bringing that window 
>to
> > the front of the window stack - or, if the "donating" process loses 
>focus
> > at the wrong moment, at least raising the "receiver" process's windows 
>to
> > be on top of the "doner"'s windows in the window stack?
> >
> > The reason I want to do this is that I have a multiprocess application,
> > consisting of a master process (with a selector window) and a number of
> > child processes started from the selector window.  These child processes
> > are unique applications in the sense of KUniqueApplication - if a given
> > child has already been started, a second start request from the user 
>should
> > simply bring the running child to the front of the window stack.  
>However,
> > since the application is written in non-KDE Qt, I can't use
> > KUniqueApplication for this.  I am currently sending a 
>_NET_ACTIVE_WINDOW
> > client message to the window to be raised and calling XMapRaised on it.  
>Is
> > this considered acceptable?
>
>  Yes, if you do it the right way. The _NET_ACTIVE_WINDOW message in the 
>window
>manager spec (http://standards.freedesktop.org/wm-spec/wm-spec-latest.html)
>has a support for passing activity to another window, see its description 
>for
>details (set properly source indication and set the requestor's window to 
>the
>master app's active window). There is no such support for raising, but if 
>you
>activate first and raise afterwards, then just XRaiseWindow() should work
>fine if it follows a successful activation.
>
>  However, from your description, I think the really right way would be to 
>use
>application startup notification (ASN), which is also what 
>KUniqueApplication
>does. When a new application is launched, first ASN id is created and a
>message is sent with information about the launched application, then the
>application is launched, gets the id from $DESKTOP_STARTUP_ID, marks its 
>new
>window with this id and sends final message about launch being completed.
>KWin sees the id on the window and reacts appropriately (handles focus
>stealing prevention based on timestamps, uses the originally sent 
>information
>to set proper virtual desktop etc.).
>
>  You could use the KStartupInfo* classes from kdelibs for this, they're 
>under
>a permissive license, so you can copy the relevant files to your 
>application.
>The files should be just kstartupinfo.* and kxmessages.* and you probably
>will have to comment out some code that is used by the rest of kdelibs or
>KWin that is not relevant to your case, you just need to send the messages
>and set id on the window.
>
>  I'm afraid those classes are somewhat internal to the rest of KDE so 
>they're
>not very commented, but the basic idea is that you create id class
>KStartupInfoId and initialize it from KStartupInfo::createNewStartupId(),
>then create KStartupInfoData, fill in various data and send them using
>KStartupInfo::sendStartup(). Then launch the application, with
>KStartupInfo::setupStartupEnv() used to make sure it gets the env.variable
>with the id.
>
>  Then the rest is up to the launched application, it first uses
>KStartupInfo::currentStartupIdEnv() to get the id (note that Qt4 reads it 
>in
>QApplication ctor, so you need to read it before it and reset it using
>KStartupInfo::resetStartupEnv() in order to prevent Qt4 from handling it).
>Then it should be as simple as calling KStartupInfo::setNewStartupId() to 
>set
>it on your window and call KStartupInfo::sendFinish(). You can set the id 
>on
>a new window before its shown or on an already existing window, it doesn't
>matter, that window will be simply handled as a result of the application
>launch. If you use some other means for talking to an already existing
>application like IPC, then instead of using the env.variable pass the id 
>that
>way.
>
>  This approach should work with KWin, it should also work with Metacity or 
>any
>other window manager supporting focus stealing prevention (although I 
>suggest
>at least briefly testing) and it should also work with other window 
>managers
>since KStartupInfo::setNewStartupId() tests if the WM has any support and 
>if
>not it simply forces the window to become active (although in a less nice 
>way
>than passing activity as described above).
>
>  I hope I didn't forget anything important in the description, if you have 
>any
>further questions feel free to ask.
>
>--
>Lubos Lunak
>KDE developer

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

_______________________________________________
Kwin mailing list
Kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]