GNOME Bugzilla – Bug 558547
Wish: Option to store / Set Status
Last modified: 2018-05-22 13:16:48 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
*** Bug 558289 has been marked as a duplicate of this bug. ***
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).
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.
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.
Created attachment 136041 [details] [review] New solution against current git HEAD This patch fully implemented the functionality as described in this bug.
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.
Thanks for your contribution. I tried to run empathy with your patch and got this crash: Program received signal SIGSEGV, Segmentation fault.
+ Trace 215933
Thread 140156427319200 (LWP 20634)
Thread 140383129147296 (LWP 25242)
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.
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.
News about an improved patch Almer?
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?
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.
*** Bug 588954 has been marked as a duplicate of this bug. ***
(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?
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.
Any chance this will be implemented soon? It really is a desirable feature...
-- 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.