Raising Windows

[David Edmundson]

On Thu, Jun 9, 2011 at 12:48 PM, Thomas Lübking
<thomas.luebking at gmail.com> wrote:
> Am Thu, 9 Jun 2011 11:51:56 +0100
> schrieb David Edmundson <david at davidedmundson.co.uk>:
>
>> The problem is that due to the design of telepathy the contact list
>> and the window that displays a chat work as two completely separate
>> applications, with communication over dbus.
>> ...
>> However the documentation for KWindowSystem::forceWindowAcitve implies
>> that it's very naughty to use it.
> Yes, it is ;-)
>
> The best way to do this is to hint the WM that the windows belong
> together, eg. by setting the same leader (which can but does not have
> to be one of the windows) or setting one as transient for the other
> (what has other effects depending on the window type of the transient
> one)
>
> For the beginning, try KWindowSystem::setMainWindow() what will create
> the transient connection and is - given your description - likely what
> you want (eg. a QDockWidget is transient for it's main window)
> You'd likely call that in the contact list and need to know
> Widget::winId() from the message window.

Thanks, unfortunately that doesn't really fit our needs. In Telepathy
everything is designed to be modular and replaceable - This chat
window can be launched from our contact list, empathy (Gnome's
client), plasma, and krunner. (and that's just the stuff planned).
The contact list can also close before the chat window, and/or be
re-opened.

Each of these can't be expected to find out the Chat Windows WId.
Especially as the chat window could be replaced by a different
application.

>
> To fake a group connection, you'll unfortunately but likely (i'm not
> really sure...) have to set the releavant property using X11 directly
> (XChangeProperty), so rather first try whether the above suits you well.
>
>> I assume for the other two, KWin is suppressing my call to activate
>> the window (though I'm guessing here) because you think the user is
>> busy using a different application.
> Yes. This is often caused by acting on mouse press instead of release,
> but the timestamp check is faaaar more wonky than an explicit
> connection, so the latter one is preferable.
>

> Cheers,
> Thomas
>