Opened 9 years ago

Closed 8 years ago

#12451 closed patch (fixed)

XMPP: default user directory configuration

Reported by: SgtPepper Owned by: deryni
Milestone: 2.8.0 Component: XMPP
Version: 2.7.2 Keywords:
Cc:

Description (last modified by SgtPepper)

This patch satisfies enhancement ticket #12328.

It provides a user configurable option for the default server chosen for the "Enter a User Directory" dialog (displayed when "Search for Users..." is chosen from the account menu).

This value is currently only pre-populated when the XMPP server responds to a disco#info with user directory information. This patch allows the user to override this with any server of their choice.

There are multiple cases where this would be tremendously useful.
Two such use-cases:

  1. An XMPP server does not advertise a user directory using disco#info. In this case (my case), the user would have to type in the user directory server (and remember what it is) every time they want to search for a user. With this patch, they can enter it once and not worry about it from then on.


  1. A user connects to one jabber server (that may or may not advertise a user directory), but typically searches for users from a different XMPP service. This user would want to override the default user directory server to be the one they typically use so they don't have to type it in every time.

Thoughts?

Attachments (3)

default_user_directory.patch (1.9 KB) - added by SgtPepper 9 years ago.
Default user directory patch
default_user_directory.2.patch (2.0 KB) - added by SgtPepper 9 years ago.
Default user directory patch - take 2
default_user_directory.3.patch (1.7 KB) - added by SgtPepper 9 years ago.
Default user directory patch - remembering last entered value

Download all attachments as: .zip

Change History (13)

Changed 9 years ago by SgtPepper

Default user directory patch

Changed 9 years ago by SgtPepper

Default user directory patch - take 2

comment:1 Changed 9 years ago by SgtPepper

Small amendment:

Due to an "inconsistency"* in how Pidgin handles its settings, I've added a check for an empty string along with the check for a null pointer.

  • If a setting is empty when Pidgin launches, purple_account_get_string returns NULL (the default value). If the user sets (or has it set on launch) a setting then changes it back to empty, purple_account_get_string returns "" (empty string). This is, in my opinion, a bug, but I'll just work around it here.

comment:2 Changed 9 years ago by darkrain42

Ticket #12328 has been marked as a duplicate of this ticket.

comment:3 Changed 9 years ago by darkrain42

  • Milestone set to Patches Needing Review

Or just change the default value to "" instead of NULL (which is my preference, since it simplifies the code).

That said, I really would like to avoid adding another setting to the advanced tab for XMPP accounts (there are too many already), especially one that I think I is going to be used by only a very small number of people

comment:4 Changed 9 years ago by QuLogic

Is it really necessary to have a preference for this?

Wouldn't it be nicer to just save the last used server and auto-populate with that? Or to be really nice, have a sort of dropdown like the auto-complete for buddies with the last 10 or something servers.

comment:5 follow-up: Changed 9 years ago by SgtPepper

  • Description modified (diff)

Sorry for the delay in response. These messages were being marked as spam...

I'd be happy with any solution that doesn't require entering the server every time a user search is performed. I'm currently making custom Pidgin builds for myself and others who find this very annoying (some of who were going to switch to less functional clients due to this), but I'd rather not need to do so indefinitely.

However, having it based on some history mechanism would be a change in behavior for people that currently do receive a disco#info with user directory information. Though, perhaps that is acceptable.

Having it remember a the last server entered would work fine for the first use case, but it could get frustrating in the second use case: You search for users 99% of the time from one user directory server, but after you do it once on another server you have to reenter your primary directory server. However, you would only have to enter it again once each time this happens, so it may not be a big deal. Also, my case is the first use case, so I'm not going to fight terribly hard for a solution to the second use case if you guys aren't concerned about it.

As far as not wanting to add another setting to the advanced tab for XMPP: Is it really a problem to add a fairly self-explanatory setting there that doesn't have to be populated? There would be no more text fields for XMPP than there are for other protocols (I'm looking at Yahoo! right now, and it has 5 text fields - which is the same as XMPP would have with this field).

Thoughts?

comment:6 in reply to: ↑ 5 Changed 9 years ago by darkrain42

Replying to SgtPepper:

As far as not wanting to add another setting to the advanced tab for XMPP: Is it really a problem to add a fairly self-explanatory setting there that doesn't have to be populated? There would be no more text fields for XMPP than there are for other protocols (I'm looking at Yahoo! right now, and it has 5 text fields - which is the same as XMPP would have with this field).

We fairly often have people confused about the fields that are already there (which I find self-explanatory!), and in fact are confused over the fact things on the Advanced tab can be left at the default value of blank, so I do think this would cause some confusion (though at the same time, I acknowledge attempting to appeal to the lowest common denominator is foolish) -- I would imagine there just aren't that many (as a percentage) XMPP users who use user directories.

I do like QuLogic's suggestion.

comment:7 Changed 9 years ago by SgtPepper

Is there precedence somewhere for persistently remembering the last entered value of a text field (aside from statuses, which have their own file)? I'm okay with that solution, but if I'm going to write such a patch, I'll have to know how such a value should be stored/retrieved (just as an accounts.xml setting as in my patch - just storing the last used value instead of an "Advanced" setting?).

Forgive me if this is obvious. I'm not overly familiar with Pidgin's code (or even GTK+, for that matter), so I could be missing something right in front of me.

However, based on my current assumptions, please see the following patch. If a value different than the disco#info is provided, it is persisted. If a value the same as disco#info is provided, the persisted value is cleared. I only persist the value if it is different, so that the disco#info data can change and still be used. I clear the value for the following use case:

  1. Default is provided by disco#info
    1. May or may be used to search for users
  2. User uses a different directory to search for a user
  3. User wants to use the server that happened to be provided by disco#info
    1. If I didn't clear the persisted value, the directory from 2. would continue to be persisted and used as default on subsequent searches
    2. Since it is cleared, the default value starts following disco#info again until the next non-matching server is entered.

Changed 9 years ago by SgtPepper

Default user directory patch - remembering last entered value

comment:8 Changed 8 years ago by darkrain42

  • Milestone changed from Patches Needing Review to 2.8.0

SgtPepper?: What name and email address should be used for credit?

comment:9 Changed 8 years ago by SgtPepper

Keith Moyer pidgin@…

comment:10 Changed 8 years ago by pidgin@…

  • Resolution set to fixed
  • Status changed from new to closed

(In 726c5220207c01e8799797c7d6d4455d23159281):
jabber: Remember the last-used user directory. Closes #12451

Patch from Keith Moyer.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!