| Commit message (Collapse) | Author | Age | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
Requires libpurple 2.12.0
Mostly relevant recently with slack-libpurple.
|
| |\| |
|
| | |
| |
| |
| | |
Noisy but often important
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
That is, flagged with PURPLE_MESSAGE_DELAYED. Those are safe to display.
This is similar to what adium does. Thanks EionRobb for the idea.
|
| |\| |
|
| | |
| |
| |
| |
| | |
This one was caught by the debian build scripts in travis. I had
format-security in my local cflags, not format-string. Welp.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds channel settings prefixed by purple_. For example jabber now
has purple_room and purple_server which are decomposed variants of our
own 'room' setting. Okay, that doesn't sound very useful.
It also adds some sync from the values returned by chat_info_defaults()
- so if the plugin figures something out in there, we save it in our
own settings.
In the case of SIPE this adds a new setting, purple_uri, which can be
set with the ma-chan:// uri for a persistent chat.
This solves the issue with the SIPE plugin only knowing how to do name
lookups after doing 'chat list' - now it just needs to work once, and we
save the real URI in our settings.
|
| | |
| |
| |
| |
| |
| | |
Because crashing asserts are bad, and maybe this helps fix the
captures_build_path issue with debian's reproducible builds
(those asserts probably include __FILE__)
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The whitelist includes hangouts, funyahoo and icq.
These plugins tend to have numeric or meaningless usernames. With this
change, users don't have to do 'ac whatever set nick_format %full_name'
anymore. Just sugar.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
The room names in 'chat list' were missing the server part.
Jabber is the only prpl which implements this method as far as I can
see, and it's needed to get the full name.
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
This adds a prpl_options_t enum with flags, which mostly just brings
OPT_PROTO_{NO_PASSWORD,PASSWORD_OPTIONAL} from libpurple as
PRPL_OPT_{NO_PASSWORD,PASSWORD_OPTIONAL}
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This means cancelling transfers on logout to avoid crashes, keeping
track of timeouts, reffing and unreffing the xfers, listening to the
callbacks from UI and purple more carefully and using the correct
functions to free the correct things at the correct moments.
Originally intended to fix a crash triggered when the dcc stall timeout
kicks in after the account is offline, which is apparently very frequent
with telegram (it sends file transfers while fetching history, and
randomly disconnects a while later).
Trying to fix that meant opening a can of worms, but after three days of
work on this bug I'm pretty sure I've finished dealing with the
resulting mess and tested all the typical edge cases.
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Because our purple module is all about hacks, adding more can't hurt.
There's a string comparison for "Enter a Conference Server". It's
gettexted in the source but in practice it isn't affected by locale
(bitlbee disables localization).
Worst case, if this stops working, it will open an input request like it
did before this commit. It also does that in purple's jabber if you
don't provide a server parameter.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Which happens when moving from non-purple to purple.
Fixes trac ticket 1269
Since "oscar" doesn't exist in purple, the old code called
register_protocol() to associate oscar with prpl-aim, which meant that
aim accounts migrated seamlessly to purple but icq accounts broke
silently, throwing incorrect password errors.
Now the oscar protocol is special-cased to return prpl-aim or prpl-icq
depending on the first character of the username, which is the same
thing the built-in oscar protocol does.
|
| |\| |
|
| | |
| |
| |
| |
| | |
I found myself copypasting this to jabber. Might as well make it part of
the API.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
bee_chat_list_finish is still available as a deprecated function but it
will be removed before the next stable release
It has never been part of any release, just keeping it for a while for
the sake of being polite to the users of the discord plugin who may be
using the experimental chat list branch.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Two issues here:
1. SIPE called in_progress(FALSE) immediately (which decreases refcount),
before purple_roomlist_get_list() could return (which would normally
increase refcount). The first refcount decrease steals it from the prpl,
and bad things happen.
Added an initialized flag to only do that decrease after it was
increased first. This is similar to how pidgin sets a 'dialog' attribute
after the purple_roomlist_get_list() call, and skips the unref if it's
not set.
2. The code assumed that NULL return value means room listing not
supported. That's not quite true, so now it checks in the prpl info to
see if roomlist_get_list is defined.
Also, made purple_roomlist_data more private.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Follow up to a3019499665384a3dcbbc11016d256e6d4dcd26c (which actually
made things worse than before for this particular case - found it by
bisecting)
This affected skypeweb and hangouts, maybe others.
Sometimes serv_join_chat() results in a call chain like this
(outermost frame first)
1. purple_chat_join
2. serv_join_chat
3. (the join_chat function of the prpl)
4. serv_got_joined_chat
5. purple_conversation_new
6. prplcb_conv_new
The last one tries to find a struct groupchat by name (that's the code
from the referenced commit). If it doesn't exist, it creates a new one.
This usually isn't an issue because the 4th step is done asynchronously,
and a groupchat is created at the end of purple_chat_join. If it's not,
you end up with two groupchats, which can lead to other nasty issues.
This moves the creation of the groupchat right before serv_join_chat().
That way, it always exists even if the conversation is created
immediately.
|
| |\| |
|
| | | |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| | |
This only happens if the user has used / forced daemon mode (for
example, when debugging with BITLBEE_DEBUG=1)
|
| |\ \ |
|
| | |/ |
|
| | | |
|
| | |
| |
| |
| | |
This reverts commit e83d450ef16d9a3783f5daff632c4ac57ceb8fec.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows adding bitlbee-specific purple plugins in a directory
controlled by the user who starts bitlbee (as it can be defined in
bitlbee.conf, PluginDir).
Pidgin and finch have something similar allowing users to place plugins
in ~/.purple/plugins:
path = g_build_filename(purple_user_dir(), "plugins", NULL);
The direct equivalent would be to use our config dir, but i'd rather not
put executable modules there.
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
Fixes trac ticket 1255, which points out that a strip_html() call down
there may modify the passed string, and some purple plugins may pass
read-only string data to it.
|
| | |
| |
| |
| |
| | |
it has changed, this is useful for accounts using oauth e.g.
purple-hangouts.
|
| |/ |
|
| |
|
|
| |
It was showing 'secondary' only before.
|
| |
|
|
|
|
|
|
|
|
| |
Those are purple_conversation_write with PURPLE_MESSAGE_SEND flag set,
received through the write_conv UI op.
write_chat and write_im still receive and filter PURPLE_MESSAGE_SEND.
In the case of write_chat it *could* show some of those, but it seems
there's no decent way to tell echoes apart from remote self-messages.
So just keep those hidden for now.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
It was passing the wrong data to the callback - it was supposed to pass
the data of the PurpleMenuItem but it passed the PurpleMenuItem itself.
Probably also applies to other protocols too. It worked fine with
jabber, which i'm guessing is what this code was tested with originally.
It still whines about the null return value saying "(Possible) failure"
but, eh, whatever.
|
| |
|
|
|
|
|
|
| |
Purple's IRC, for example, doesn't have the PURPLE_CONNECTION_HTML flag,
but still sends html for format codes.
Note that using IRC through libpurple through bitlbee is still a
terrible idea. Use ZNC instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Which has no connection context. Luckily local_bee exists, and libpurple
only supports only one irc user per process.
This sucks.
And yesterday I was naively thinking (again) that local_bee might not be
needed, that maybe we can do things properly. Of course it only took a
look at that one reverted commit (56985aa) to remember that life is
unfair, and that, under Moloch, everyone is irresistably incentivized to
ignore the things that unite us in favor of forever picking at the
things that divide us in exactly the way that is most likely to make
them more divisive. That being said, I think all these hacks are going
to look nicer once I sandbox the whole thing in a separate process with
one IM account per process, as opposed to one irc use per process. Then
we'll be able to rely on global state exclusively, which is saner.
|
