309146 2012-10-28 13:59:27 +0000 'Audio Call' button opens call-ui although the call-ui-window is already open 2014-05-15 15:10:04 +0000 1 1 10 Unmaintained telepathy call-ui 0.5.0 Gentoo Packages Linux RESOLVED FIXED NOR normal Future 1 lukas.schneiderbauer kde-telepathy-bugs-null heri+kde kde mayank25080562 http://commits.kde.org/telepathy-call-ui/70c319c79aee4c4829587cfa7a53a3e1518378f6 0.8.1 0 oldest_to_newest 1310215 0 lukas.schneiderbauer 2012-10-28 13:59:27 +0000 The 'Audio Call' button opens call-ui despite the fact that it is already openend. This results in weird behaviour. For example if an active call is going on and you press the 'Audio Call'-button again (for whatever reasons) a second window opens and one is tempted to close it again because it shows the exact same information the other call-ui window does. But with closing the window the active call-connection gets closed as well. This is likely not what the user intended to do. Reproducible: Always Steps to Reproduce: 1. Open chat-ui 2. Click 'Audio Call' 3. Click 'Audio Call' again Actual Results: A second call-ui window appears. Expected Results: Maybe a focus-switch to the existing window would be a solution. (?) 1333637 1 kde 2013-01-20 13:50:00 +0000 Confirmed bug in Call-UI. It is always up to a handler when told to handleChanenls to check if it is already handling the channel. Current code does not. 1357910 2 heri+kde 2013-04-06 10:18:08 +0000 Does this persist in 0.6.0? 1357913 3 kde 2013-04-06 10:20:04 +0000 Yes. 1433215 4 mayank25080562 2014-02-28 18:31:48 +0000 This also happens with the "Video Call" button. Can this be solved, by disabling the button soon the button is clicked, and then re-enabling it once the call-ui is closed ? 1433216 5 kde 2014-02-28 18:33:12 +0000 >Can this be solved, by disabling the button soon the button is clicked, a What would happen then if you opened a video call from the contact list, and then opened a text chat? >and then re-enabling it once the call-ui is closed ? how will you know when this happens? 1433217 6 mayank25080562 2014-02-28 18:41:13 +0000 We could make use of chat logger, logging in a message once you start a video call, and logging again when you hangup, thus knowing when to disable and when to re-enable again ? 1433219 7 kde 2014-02-28 18:43:54 +0000 No that's a massive hack. The simplest approach is for the call-ui to see if it's already handling a call when it's told to handle the second one. It's all in the same process. See #1 1433220 8 mayank25080562 2014-02-28 18:52:30 +0000 Yeah right! I was inspired to do this, as in gmail chat, you get to see when you started a call, and when it ended. But to check whether it is handling a call, one would be needing a global parameter to check for, right ? 1434031 9 mayank25080562 2014-03-05 22:46:59 +0000 https://git.reviewboard.kde.org/r/116623/ 1436257 10 mklapetek 2014-03-18 15:23:27 +0000 Git commit b4626ae5b866464d9abfa2762b979224dbb4b589 by Martin Klapetek, on behalf of mayank jha. Committed on 18/03/2014 at 15:22. Pushed by mklapetek into branch 'kde-telepathy-0.8'. Removes duplication of call-ui window for a single channel REVIEW: 116623 FIXED-IN: 0.8.1 M +5 -3 src/call-handler.cpp M +2 -0 src/call-handler.h http://commits.kde.org/telepathy-call-ui/b4626ae5b866464d9abfa2762b979224dbb4b589 1448604 11 kde 2014-05-15 15:10:04 +0000 Git commit 70c319c79aee4c4829587cfa7a53a3e1518378f6 by David Edmundson, on behalf of Vadim A. Misbakh-Soloviov. Committed on 15/05/2014 at 15:10. Pushed by davidedmundson into branch 'kde-telepathy-0.8'. Properly removes duplication of call-ui window for a single channel. Fixes issue, made by b4626ae5b866464d9abfa2762b979224dbb4b589, where call-ui dont make call at all, due to the typo in condition. REVIEW: 118151 M +1 -1 src/call-handler.cpp http://commits.kde.org/telepathy-call-ui/70c319c79aee4c4829587cfa7a53a3e1518378f6