| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
| |
This patch was culled from Debian#530893.
committer: Paul Aurich <darkrain42@pidgin.im>
|
|
|
|
|
|
|
| |
Patch from Stefan Becker with minor addition by me.
committer: Paul Aurich <darkrain42@pidgin.im>
|
|
|
|
|
|
|
|
|
|
| |
Patch mostly from Aman "tmm1" Gupta; I added the g_list_prepend calls.
The functionality is going to get whacky when dealing with chats that
share the same name ("MSN Chat"), but purple_find_conversation_with_account
doesn't work for those in any sense of the word 'work', so...
committer: Paul Aurich <darkrain42@pidgin.im>
|
| |
|
|
|
|
| |
Refs #8556.
|
|
|
|
|
| |
This turned out to be cleaner than I first thought, so here we go.
All libpurple DNS routines support IDN when built against GNU libidn.
|
|
|
|
| |
people. Thanks to the msn-pecan project for this idea.
|
| |
|
|
|
|
|
|
|
|
| |
Also fix two small issues: an invalid write in jabber_close when
there is no open connection and the fact that jabber_id_new is now
much more restrictive and won't validate "foo@bar.com/", which is what
the PurpleAccount username looks like (since Pidgin defaults to an
empty Resource).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
So I was finally able to reproduce this. "Close IMs immediately" was
disabled and in the Message Notification plugin's settings, everything
is disabled except "[Notify for ]IM windows" and
"Present conversation window".
In my testing, this did not prevent the conversation from re-attaching
when a new message comes on. Fixes #8911.
|
|
|
|
|
|
|
|
|
|
|
| |
I made configure fail if libidn is unavailable and force_deps is set
because glib's UTF-8 strdown and casefold operations fail one of the
tests I've updated (based on running the tests with libidn).
Running without libidn will still work in almost every case because people
use all-ASCII JabberIDs and I had to search a fair amount to find
characters for which GLib failed. This shouldn't have a performance impact
on top of Mark's optimizations for all-ASCII JIDs.
|
|
|
|
|
|
|
|
| |
Apparently Aman "tmm1" Gupta has a lot of groups in his buddy list,
so he wrote this patch.
committer: Paul Aurich <darkrain42@pidgin.im>
|
|
|
|
|
| |
This should be a fatal condition and not finding a cached certificate
is *not* the same as "the certificate changed".
|
| |
|
|\
| |
| |
| | |
and '8c72051dc07d820e6bdc78f0908fa6664c2da0b2'
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
For backward-compatibility (and what I, as someone who knows that
Jabber supports rich-text, would expect), continue sending it if the
contact is offline (i.e. not on the roster).
|
|/ |
|
|
|
|
|
|
|
| |
Patch from Aman "tmm1" Gupta.
committer: Paul Aurich <darkrain42@pidgin.im>
|
|
|
|
|
|
|
| |
Patch from Aman "tmm1" Gupta.
committer: Paul Aurich <darkrain42@pidgin.im>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
File" menu item to save a permanent copy.
Playback uses purple_sound_play_file, which uses a playbin. This will not
correctly play back the Siren codec until Bug 588218 is fixed, but that
looks like it will be soon.
Also, if anyone has a better idea for GtkIMHtml->PidginConversation than
g_object_[gs]_data, feel free to fix it.
References #393.
|
|
|
|
| |
have gone out yet
|
| |
|
| |
|
|\
| |
| |
| |
| |
| | |
1c99d31c85e20c70f330ebe29a548b3036b5cd7e)
to branch 'im.pidgin.pidgin' (head 8d75ebb8ba36d541f5e3f3234798b5b09028d41a)
|
| | |
|
|\ \
| | |
| | |
| | | |
and 'b0ea939829a3c6d164d6dd1c4cd55ac7bcfa896e'
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Based on patch from notak and galt, but using imgstore instead of a custom
smiley (like AIM DirectIM), and with better error checking.
References #393.
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | | |
and '97912f77c231cf7f7d69e754b401da46ce7d7c8d'
|
| |\ \
| | |/
| |/|
| | | |
and 'd9dc5a8507a756a79d13db892272fd50b54f8a65'
|
| | |\
| | | |
| | | |
| | | | |
and '4748f6f20198cce030c07da18c91dd6796041a80'
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
and 'c136491361eb30a772bc638aac45c177e7a8b949'
|
| |/ / / |
|
|/ / / |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
#3300.
I don't really know why this is a setting, given that the server can
reasonably determine a client's interest based on an initial request at
login (which is what the google:mail:notify doc still says). Moreover,
they explicitly say clients shouldn't set this setting to false.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
and 'd72ae533999f88b37251c9ac8980b5f3265abd0b'
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
from Meebo.
SRV records have two fields that determine the order in which the results
should be used:
1. Priority (which we call "pref" for some reason). Records with a
lower priority will be used first.
2. Weight. Records with a higher weight are more likely to be used
first, but there is some amount of randomness. We were actually
doing this backwards and using records with lower weight first. And
we weren't randomizing. But now we are.
|
|/ / / |
|
|/ / |
|
|/ |
|
|
|
|
| |
Refs #9338.
|