After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 558547 - Wish: Option to store / Set Status
Wish: Option to store / Set Status
Status: RESOLVED OBSOLETE
Product: empathy
Classification: Core
Component: General
2.24.x
Other Linux
: Normal enhancement
: ---
Assigned To: empathy-maint
empathy-maint
: 558289 588954 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-10-30 14:49 UTC by Max
Modified: 2018-05-22 13:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch that implements the functionality partially (7.20 KB, patch)
2009-03-08 16:33 UTC, Almer S. Tigelaar
reviewed Details | Review
New solution against current git HEAD (23.70 KB, patch)
2009-06-06 00:39 UTC, Almer S. Tigelaar
reviewed Details | Review

Description Max 2008-10-30 14:49:03 UTC
Dear Empathy devs,

one of the most important features in an IM client for me is the ability to automatically restore a particular state when re-starting my IM client. For example, on my work machine I have it set to "Busy" and started on login.

Therefore, I would like to have the following config options:

Status on Start:
- Available
- Away
- Busy
- Restore from previous session

Thanks

Max
Comment 1 Almer S. Tigelaar 2009-03-08 16:28:38 UTC
*** Bug 558289 has been marked as a duplicate of this bug. ***
Comment 2 Almer S. Tigelaar 2009-03-08 16:33:54 UTC
Created attachment 130287 [details] [review]
Patch that implements the functionality partially

The attached patch adds an option to Empathy for restoring the previous state on start-up automatically. It works, but could certainly be improved a bit UI-wise. It does not allow setting a default state for start-up (as requested in this bug and its duplicate), but only offers a single option to restore the previous presence state on start-up. This could be extended of course ...

I have mailed to this patch to the mailinglist and the lead developers, but no reaction so far unfortunately ... To avoid this patch from 'falling of the radar' I am attaching it here for future reference (with a better/smaller diff of the glade file than in the original patch that I send to the mailinglist/devs about a week ago).
Comment 3 Guillaume Desmottes 2009-04-16 14:40:17 UTC
Thanks for your patch and sorry for the long reply delay.

Unfortuntally it can't be applied because we just switch from libglade to GtkBuilder.

Anyway, as said on this bug, I think the right way to solve this issue is to remove the "auto connect" option in the preferences dialog and replace it by something like that:

Status at startup:
( ) Use last status
(x) Use this status: [Available]

Using 2 toogle buttons and a combobox listing the different statuses.
Comment 4 Almer S. Tigelaar 2009-06-05 18:37:25 UTC
I forgot to add myself to the cc list, so only saw your comment today. Great suggestion. I'll cook up a new patch for this.
Comment 5 Almer S. Tigelaar 2009-06-06 00:39:51 UTC
Created attachment 136041 [details] [review]
New solution against current git HEAD

This patch fully implemented the functionality as described in this bug.
Comment 6 Almer S. Tigelaar 2009-06-06 00:44:32 UTC
Okay, that patch took a bit longer to create than I hoped :) I'd appreciate quick feedback, since it is easier for me to improve a patch recently after I create it.

Quick notes:
1) I've attempted to make my additions in a way which is consistent with the existing code (and without hacking around too much).
2) I have not used the PresenceChooser widget as that would be overkill for the preferences dialog. I think the current solutions is more elegant (it still shares similarities with the chooser, really minor code duplication here).
3) The reason that 'restore_state' is stored as a string is for compatibility with the existing functions in the preferences dialog. It could be made into a 'bool', but the current solutions is more readable (especially when you use a tool like e.g. gconf-editor, the keys make more sense this way).

Let me know if there's anything to polish.
Comment 7 Guillaume Desmottes 2009-06-09 10:00:15 UTC
Thanks for your contribution.

I tried to run empathy with your patch and got this crash:
Program received signal SIGSEGV, Segmentation fault.

Thread 140156427319200 (LWP 20634)

  • #0 main
    at empathy.c line 594

Thread 140383129147296 (LWP 25242)

  • #0 *__GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #1 *__GI_abort
    at abort.c line 88
  • #2 IA__g_assertion_message
    at /build/buildd/glib2.0-2.20.1/glib/gtestutils.c line 1301
  • #3 empathy_idle_set_presence
    at empathy-idle.c line 632
  • #4 main
    at empathy.c line 606


I think we should list all the saved preset statuses. Maybe we should use the PresenceChooser widget? Don't know if it has API to set it in "read-only" mode.
Davyd: what do you think?

Having 3 new GConf keys seems to much. Would be good to reduce that if possible.

If you are using git, feel free to post the address of the branch.
Comment 8 Almer S. Tigelaar 2009-06-10 07:37:45 UTC
Thanks for you review.

1) I did not know about tp_strdiff. I'll use that in a next version of the patch instead of strcmp.

2) The crash is (I suspect) because you have not installed the schema correctly (the schema provides defaults). Of course, I could make safeguards in the code for this, but I think it is a reasonable assumption to assume that the gconf schema is installed. You can install the schema (after a 'make install') with 'gconftool-2 --install-schema /<prefix>/etc/gconf/schemas/empathy.schemas

3) I considered using 2 (instead of 3) gconf keys. However, this unnecessarily bloated the code, so I decided to keep the keys one-on-one with the preferences dialog (2 options = 2 keys + state saving = 1 key). I think this is a sound choice.

4) I started using the PresenceChooser. However, changing state there, directly affected the current on-line state (which is not what a user wants when in the presence dialog). Additionally, it should not list an initial state of 'Offline' (since that is equivalent to not auto connecting at all). Also, being able to set 'custom' messages (saved presets) as state will make it somewhat hard to restore state if the messages are removed again later. I am unsure if we should add that at this point. Maybe we should keep it simple and stick to the current limited set of options?

5) I am using a local (non-exported) branch, So we'll do with patches for now.
Comment 9 Nicolò Chieffo 2009-07-08 23:04:55 UTC
News about an improved patch Almer?
Comment 10 Almer S. Tigelaar 2009-07-09 17:35:52 UTC
I can make a version with tp_strdiff (see my previous comment). But I am wondering if any other changes should be made to the patch (again, see my previous comment). Guillaume?
Comment 11 Nicolò Chieffo 2009-07-09 17:56:48 UTC
2) if providing a default value will fix the crash you have to do it, it is unacceptable that a program crashes only if a gconf key is missing

3) you can merge the 2 options in one: NONE, RESTORE, EXPLICIT.
then use these 3 simple functions:

gboolean
automatic_state_is (const gchar* value) {
   gchar* key_value;
   key_value = empathy_conf_get_string (empathy_conf_get (),
           EMPATHY_PREFS_AUTOMATIC_STATE);
   return !tp_strdiff (key_value, value);
}

gboolean
automatic_state_is_restore () {
  return automatic_state_is("RESTORE");
}

gboolean
automatic_state_is_explicit () {
  return automatic_state_is("EXPLICIT");
}

4) if the presence chooser automatically changes the status, it's worth to not use it, and use a simple widget.
Comment 12 Guillaume Desmottes 2009-07-20 16:00:31 UTC
*** Bug 588954 has been marked as a duplicate of this bug. ***
Comment 13 tvst 2009-11-04 19:19:09 UTC
(In reply to comment #8)
> Thanks for you review.
> 
> 1) I did not know about tp_strdiff. I'll use that in a next version of the
> patch instead of strcmp.
> 
> 2) The crash is (I suspect) because you have not installed the schema correctly
> (the schema provides defaults). Of course, I could make safeguards in the code
> for this, but I think it is a reasonable assumption to assume that the gconf
> schema is installed. You can install the schema (after a 'make install') with
> 'gconftool-2 --install-schema /<prefix>/etc/gconf/schemas/empathy.schemas
> 
> 3) I considered using 2 (instead of 3) gconf keys. However, this unnecessarily
> bloated the code, so I decided to keep the keys one-on-one with the preferences
> dialog (2 options = 2 keys + state saving = 1 key). I think this is a sound
> choice.
> 
> 4) I started using the PresenceChooser. However, changing state there, directly
> affected the current on-line state (which is not what a user wants when in the
> presence dialog). Additionally, it should not list an initial state of
> 'Offline' (since that is equivalent to not auto connecting at all). Also, being
> able to set 'custom' messages (saved presets) as state will make it somewhat
> hard to restore state if the messages are removed again later. I am unsure if
> we should add that at this point. Maybe we should keep it simple and stick to
> the current limited set of options?
> 
> 5) I am using a local (non-exported) branch, So we'll do with patches for now.

Since these questions have not been answered in the past months, why not simplify things for now and just offer the following two options:

Status at startup
( ) Use last status
( ) Start as "available"

where the last option would at some point be replaced by
( ) Use this status: [available |v]


The main point I'm trying to make here is that this bug report is actually made of two feature requests. Just look at the bug title, which can be decomposed into "option to store status" and "option to set status". So why not resolve the first feature request (since it is simple to fix) and leave the second for a later time?
Comment 14 Danielle Madeley 2009-11-04 22:06:54 UTC
So, it seems to me that in our MC5 enabled future, we really don't want Empathy to feed any status to MC5 on startup. Instead we could expose the AutomaticPresence option from MC5 as a preference. That way Empathy is less tied to the lifetime of the Telepathy connections.

This seems a lot neater.
Comment 15 Mehmet Giritli 2010-07-10 13:57:16 UTC
Any chance this will be implemented soon? It really is a desirable feature...
Comment 16 GNOME Infrastructure Team 2018-05-22 13:16:48 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/30.