When auto-away is enabled, when you are no longer away, the status should be restored, while it just stays "away" until you manually change it
I think I managed to fix this. Can you please retest with latest master and reopen if it still happens? Thanks
Hi, I'm using 0.5 - ktp-kded-integration-module-0.5.0-1.fc18.x86_64 - now and still experience this issue. Martin Kho
Hi, I did some little more testing and found that only the first time it fails to restore the status. The following is happening: 1. ktp is automatically loadad after log in, I'm asked for my password - via kwallet - and the system tray icon turns green - online. 2. After 15 minutes the system tray icon shows the "away" status and after 30 minutes the "not available" status- auto-away times has been set in the kcm-module. Pressing a key or moving the mouse has no affect. I' ve to manually change the status to available. but! 3. Now waiting 15 or 30 minutes and then pressing a key or moving the mouse does restore the available status. So IMHO, it seems that somewhere an initialization fails or is missing. Hope this helps, Martin Kho
Thanks for the extensive report Martin, I'll have a look.
Was this ever fixed? Given that people are starting to use kde-telepathy as a default in some distros (e.g. Kubuntu 12.10) it's a pretty bad problem to have.
@mgolden Hard to say, test it and report back.
Fwiw it works for me on a completely clean install of Kubuntu 12.10, returns to Available from both Away and Not Available.
I can confirm I'm experiencing this issue with 0.5.1 under KDE 4.9.2, OpenSuSE 12.2.
Does it happen every single time or just for the first time and when you change your presence manually, it works?
It only happens the first time. After that, it's able to go back to available when it detects activity.
@David Could you post your version of telepathy-mission-control-5 (part of backend behind telepathy) Also after you first connect could you run: for account in `mc-tool list` ; do mc-tool show $account | grep Presences -A 4; done in a terminal and paste the output here.
@David > Could you post your version of telepathy-mission-control-5 (part of backend behind telepathy) It's 5.12.0. > Also after you first connect could you run: > for account in `mc-tool list` ; do mc-tool show $account | grep Presences -A 4; done Presences: Automatic: available (2) "" Current: available (2) "" Requested: available (2) "" Changing: no Presences: Automatic: available (2) "" Current: offline (1) "" Requested: offline (1) "" Changing: no Hope that helped. Do not hesitate to ask me for more info.
I confirm this for Telepathy/KDE 0.5.1. It works sometimes, but often it does not.
*** Bug 316133 has been marked as a duplicate of this bug. ***
Git commit df1193c51eaea26f495b12c622cccd24faae00e2 by Martin Klapetek, on behalf of Stefan Eggers. Committed on 06/03/2013 at 12:15. Pushed by mklapetek into branch 'master'. Fix auto away not restoring previous presence the first time FIXED-IN: 0.6.0 REVIEW: 109301 M +2 -0 telepathy-module.cpp http://commits.kde.org/telepathy-kded-module/df1193c51eaea26f495b12c622cccd24faae00e2
Hi, I can confirm this issue is solved. Great work! Thanks, Martin Kho
(In reply to comment #16) > I can confirm this issue is solved. For me it is not. I am using 0.6_beta1. After login, I still have to click the presence plasmoid to get a contact list, which will then connect all accounts.
Dennis, please run: for account in `mc-tool list` ; do mc-tool show $account | grep Presences -A 4; done
(In reply to comment #18) > Dennis, please run: After login, when the accounts are not connected? Or after I opened the contactlist and observed all accounts being connected?
May as well have both.
(In reply to comment #17) > For me it is not. I am using 0.6_beta1. After login, I still have to click > the presence plasmoid to get a contact list, which will then connect all > accounts. I think you might be hitting BUG 300062 (unfortunately not fixed yet) not this one... This one was when you are already connected, if you go idle and then return at the computer, the status stays "away"
(In reply to comment #21) > I think you might be hitting BUG 300062 (unfortunately not fixed yet) not > this one... Oh, sorry, you are right!