Bug 320310 - Five-second delay before Ctrl+Alt+A brings attention-demanding chat window to front
Summary: Five-second delay before Ctrl+Alt+A brings attention-demanding chat window to...
Status: RESOLVED UPSTREAM
Alias: None
Product: telepathy
Classification: Frameworks and Libraries
Component: text-ui (show other bugs)
Version: 0.6.1
Platform: Other Linux
: NOR normal
Target Milestone: Future
Assignee: Telepathy Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-26 15:14 UTC by Haakon Nilsen
Modified: 2013-06-10 08:10 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Haakon Nilsen 2013-05-26 15:14:01 UTC
When I have an ongoing chat in a window in the background, and my chat partner sends a message there, the window "demands attention" - its entry in the taskbar blinks. I always use the standard Ctrl+Alt+A keyboard shortcut of KWin to bring attention-demanding chat windows to front. But in Text Ui, there is a delay between the windows starting to demand attention and the keyboard shortcut working – it seems like five seconds, but it's hard to tell, so I will just repeatedly press Ctrl+Alt+A until the window appears. This is frustrating, and other applications don't behave this way. If it's not a bug, it's certainly a very strange and counterintuitive feature.

Reproducible: Always

Steps to Reproduce:
1. Get someone to send you an IM message
2. Immediately when the window's taskbar entry starts blinking, press Ctrl+Alt+A
3. Nothing happens. After five seconds, goto step 2, and the window will appear as expected.



I'm using the Kubuntu packages, and they don't seem to have any newer than 0.6.1, so I have not tested on 0.6.2.
Comment 1 David Edmundson 2013-05-29 23:20:52 UTC
Works fine here. Basically instant.

Can anyone else confirm that it does or does not work for them?
Comment 2 Haakon Nilsen 2013-05-30 08:39:30 UTC
Got a friend to test, and he could reproduce it on 0.6.2.
Comment 3 David Edmundson 2013-05-30 12:48:01 UTC
Confirmed, though turns out... a bug in plasma.

What is happening is that the notification demands attention at the same time as the window. KWin selects the notification widget in plasma when you press the shortcut which doesn't do anything.

(I tend to run colibri, hence didn't see this)

output of :
for id in `xwininfo -root -tree  | grep -E "0x[0-9a-e]{7}" -o ` ; do xwininfo -id $id -wm; done | grep Attention -B 20

xwininfo: Window id: 0x280033d "plasma-desktop"

  Window manager hints:
      Client accepts input or input focus: Yes
      Initial state is Normal State
      Displayed on all desktops
      Window type:
          Dock
           Kde Net Wm Window Type Override
          Normal
      Window state:
          Demands Attention
--
  Window manager hints:
      Process id: (unknown)


xwininfo: Window id: 0x24461a7 (has no name)

  No window manager hints defined
  Window manager hints:
      Process id: (unknown)


xwininfo: Window id: 0x6c00012 "Martin Gräßlin"

  Window manager hints:
      Client accepts input or input focus: Yes
      Initial state is Normal State
      Displayed on desktop 0
      Window type:
          Normal
      Window state:
          Demands Attention



Thanks to Martin Gräßlin for suggesting that as a possibility.
Fix will need to be in Plasma, as that's where the bug is. We could bodge it by delaying the notification by a few ms, but that doesn't really fix the problem.

I'll try and fix this plasma side.
Comment 4 David Edmundson 2013-06-10 08:10:32 UTC
This review has been submitted with commit 82742975bba60311272c0bb4909635d948bb8291 by Martin Gräßlin to branch master.


Fixed in Plasma 4.11