Bug 181748 - Support setting the presence of an account
Summary: Support setting the presence of an account
Status: RESOLVED FIXED
Alias: None
Product: telepathy
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: git-latest
Platform: Compiled Sources Linux
: HI wishlist
Target Milestone: Future
Assignee: Telepathy Bugs
URL:
Keywords:
: 271612 346958 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-24 13:53 UTC by George Goldberg
Modified: 2018-04-09 19:31 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In: 18.04


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description George Goldberg 2009-01-24 13:53:02 UTC
The applet should allow users to set the presence of their IM accounts through it.
Comment 1 Abner Silva 2009-08-07 20:15:34 UTC
Feature done.

This feature was implemented on bug #181745.

Now it's possible to set presence status and message for each user account or using the global presence controller.
Comment 2 Juergen Spitzmueller 2012-01-02 08:05:24 UTC
With the recent redesign of the applet, this important feature seems to have been dropped again. Now you can only set the presence globally, not per account.
Comment 3 Martin Klapetek 2012-01-02 11:03:20 UTC
Yes, that is intended.
Comment 4 Juergen Spitzmueller 2012-01-02 12:56:04 UTC
(In reply to comment #3)
> Yes, that is intended.

You mean, it is intended to remove the feature? Why?
Comment 5 Martin Klapetek 2012-01-02 13:28:37 UTC
Yes. We introduced global presence setting as users called for this feature. However having both global and per-account presence setting breaks each other - you either have different presences or you have only one, you simply cannot mix them together. Therefore we decided to use only global presence as it makes more sense and we chose to not allow users fiddle with single account presences. 

So it was removed from presence applet and also from contact list (though you can still have the controls there by overriding config file, that's only for testing/devel purposes and it's not supported and will be removed completely).
Comment 6 Juergen Spitzmueller 2012-01-02 13:44:53 UTC
I see. Of course I accept your design decision, but I do not really see why  local setting could not simply override a global setting (as in: local accounts use global presence setting if not specified otherwise). You'd simply need a further option "Default" for the local presence selection. I do not see major conceptual differences here to how other applications handle the global/local strata (though I do not know the telepathy internals).

I also think it is a major limitation in functionality. I have currently 6 different IM accounts, each for different purposes. If I open my university jabber account for a virtual consultation hour for students or if I do a business chat, I do not want to be reachable by my private buddies; and vice versa.
Comment 7 George Goldberg 2012-01-02 13:53:18 UTC
Note that Kopete has had a method for handling this account/global presence conflict for years - Will Stephenson can probably tell you the details since I think he implemented back in the day.  

Also, I'd caution that you are in danger of getting people requesting "identities" support if you refuse to allow account-specific presence setting.  I can guarantee you that having to support "identities" is infinitely harder (with many more annoying conflict cases, not to mention the lack of support for this in the underlying telepathy stuff).
Comment 8 Martin Klapetek 2012-01-02 14:04:13 UTC
(In reply to comment #6)
> I see. Of course I accept your design decision, but I do not really see why 
> local setting could not simply override a global setting

Of course they could. The reason why they currently don't is simple - manpower.

> I also think it is a major limitation in functionality. I have currently 6
> different IM accounts, each for different purposes. If I open my university
> jabber account for a virtual consultation hour for students or if I do a
> business chat, I do not want to be reachable by my private buddies; and vice
> versa.

There's nothing easier than disabling the account in system settings (you can open that from contact list as well). Simply enable the account when you need it and disable when you don't. That's what it is for after all ;)

(In reply to comment #7)
> Note that Kopete has had a method for handling this account/global presence
> conflict for years - Will Stephenson can probably tell you the details since I
> think he implemented back in the day.  

I think it wouldn't be that complicated with our current global presence design. In fact, it would be rather easy, it's just lots of code to write. And we would need to redesign the controls. And as you know - manpower :)

> Also, I'd caution that you are in danger of getting people requesting
> "identities" support if you refuse to allow account-specific presence setting. 

We already have people requesting activities support, which I see very similar to identities support (different approach, same purpose). But no way this is going to happen soon...
Comment 9 George Goldberg 2012-01-02 14:14:52 UTC
Is it fair to conclude then, that you don't oppose having controls to set individual account presences, but that it must be done properly (not in a half-baked way that leaves loads of inconsistencies in the various UIs) and that it must be done by someone who has time to do it ;).
Comment 10 Juergen Spitzmueller 2012-01-02 14:17:04 UTC
If it's the lack of manpower, can I ask to reopen this ticket so that the feature request does not get forgotten?
Comment 11 Juergen Spitzmueller 2012-01-02 14:19:11 UTC
(In reply to comment #8)
> > I also think it is a major limitation in functionality. I have currently 6
> > different IM accounts, each for different purposes. If I open my university
> > jabber account for a virtual consultation hour for students or if I do a
> > business chat, I do not want to be reachable by my private buddies; and vice
> > versa.
> 
> There's nothing easier than disabling the account in system settings (you can
> open that from contact list as well). Simply enable the account when you need
> it and disable when you don't. That's what it is for after all ;)

Well, sure, but that's not the same than setting it to "busy" or "Not available".
Comment 12 Martin Klapetek 2012-01-02 14:28:47 UTC
Yes, it can be done and we're not strongly against it. If someone steps up to do this, we can probably help with guiding through the code. But beware that it is rather a complex task. And very important thing - we want to have a perfect UI for this, not some half-baked-sort-of-works-crap (this is imho the hardest part).
Comment 13 David Edmundson 2012-01-02 15:38:09 UTC
It's a lack of a UI design that works that's the issue (which is arguably manpower but a bit different). It doesn't matter if anyone steps up volunteering to code if they don't have a plan of what to do. (which I'd like discussed first)

The issue summarised:
 - Currently all accounts are global, this sucks for the use case like you have.
 - If we do everything on a per account (like 0.1) it's a pain for people who want to set everything online/offline etc.  

 - So we need a mix - but that sucks too.
  If we show both it takes up a /lot/ of space
  Worse if you show single account in some places and global in another you get into a real mess. Where it says "you're online" but in reality, one account is, another one is away. Something we had in KDE telepathy for a while, when the plasmoid and CL were doing different things and it was awful. It's gets very confusing. 

There is another equally important issue that hasn't mentioned yet. If you put accounts in different states, the kded (that controls auto away, MPRIS messages etc) gets itself in a real mess. This needs updating before we can change the UI behaviour. (IIRC this was one of the deciding factors for changing it to global only for 0.2)
Comment 14 Daniele E. Domenichelli 2012-01-02 16:21:54 UTC
I think this is one of the things that we could handle using activities...
We could just drop the global presence and have a configuration like the new power management, where you can choose for every activity the status for the accounts.
Then, the global presence should be just enable/disable instant messaging features.
Comment 15 Martin Klapetek 2015-05-05 11:32:31 UTC
*** Bug 346958 has been marked as a duplicate of this bug. ***
Comment 16 Jamie Smith 2017-01-10 05:55:36 UTC
*** Bug 271612 has been marked as a duplicate of this bug. ***
Comment 17 Jamie Smith 2017-11-22 01:07:38 UTC
Git commit f40dc5815e0c8e66781331ede1ffd8716d4b0921 by James D. Smith.
Committed on 22/11/2017 at 01:06.
Pushed by smithjd into branch 'master'.

Independent account presence support.
Bugfixes and improvements.
REVIEW: 130189
GUI:

M  +1    -0    CMakeLists.txt
A  +303  -0    dialogs/advanced-presence-dialog.cpp     [License: GPL (v2/3)]
A  +59   -0    dialogs/advanced-presence-dialog.h     [License: GPL (v2/3)]
M  +5    -0    dialogs/custom-presence-dialog.cpp
M  +78   -102  global-presence-chooser.cpp
M  +6    -4    global-presence-chooser.h
M  +7    -27   main-widget.cpp
M  +0    -2    main-widget.h

https://commits.kde.org/ktp-contact-list/f40dc5815e0c8e66781331ede1ffd8716d4b0921