| Commit message (Collapse) | Author | Age | Lines |
... | |
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
having this distributed together with BitlBee will hopefully make up for the
fact that BitlBee has poor binary API backward compatibility.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
MULTI_SUBSCRIBED (works only when user initiates the chat, otherwise new channel is created anyway)
|
| |/ / / |
|
| | | | |
|
| |\ \ \ |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
on windows socket/threading is needed as there are no gobject, but those
directly on linux would be suboptimal
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
BitlBee internally always uses UTF-8 (see initialization of
irc->iconv and irc->oconv in set_eval_charset in irc.c of
BitlBee's source and their usage in eg irc_vawrite in the
same file; confirmed on #bitlbee), so it makes no sense to
either get an encoding from the current locale or to make it
a runtime setting.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When using irssi in an LC_CTYPE=ISO-8859-1 terminal (thus
/set charset iso-8859-1 for irssi, set charset iso-8859-1 for
bitlbee and no recode_out_default_charset set for irssi) and
skyped.py in a Windows console window (CP1252?), sending a
message with a é (the character, not the HTML entity)
crashes the server because in its debugging output it tries to
print the UTF-8 equivalent intepreted as CP1252 code points.
I do not think that the "if options.log: ..." code just below the
patch needs the same treatment as the worst that can happen is
that some messages in the log file will be garbled. Since I do
not use/test that code path, I didn't touch it.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Sometimes skyped exits on startup because of the failure of some
underlying C lib (ie we get no expections), that's not something I want
to care about.
|
| | |\ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When TUNNELED_MODE=yes, TUNNEL_SCRIPT (when set) is used to establish a
tunnel. This allows to run skyped.py on a differnt host than the skype.c
bitlbee plugin.
|
| | | | | | |
|
| | | | | | |
|
| | |/ / / |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
So in case a user was not part of a group and it becomes (using Skype
UI), then BitlBee is now aware of this.
NOTE: current it seems the Skype part of this is broken. Use case: adding a
user to group #16 which already has a user.
<< GROUP 16 NROFUSERS 2
>> GET GROUP 16 NROFUSERS
<< GROUP 16 NROFUSERS 0
So it notifies about the number of users changed but I can't query the user
list as the number of users is then 0 - till Skype is not restarted.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
What works: if you have a few buddies in <group>, then /j &<group> will
show just those buddies.
What does not:
- If you later move buddies using Skype UI, BitlBee is not yet notified.
- You cannot move buddies using /invite yet.
What won't work in the near future: only the first group of each buddy
is parsed.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is just the begining, we do not
- store it
- store the list of users in a group nor the name of the group
- track changes after the user logged in
- don't write this info
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
On my setup (Skype 5.0.0.152), echo123 doesn't answer any chat
attempts: even if I use the official client, I get no answer, so
this test fails but not for a reason linked to the bitlbee-skype
plugin.
|
| | | | | |
|
| | | | | |
|
| | |\ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When the user disconnects from bitlbee (either by quitting or by
logging out "account skype off"), skyped should close its connection
and wait for a new connection.
This change is useful to make the test cases pass as otherwise,
skyped would not notice that the first test was done and that the
second test was trying to connect, thus leading to a failure in
the second test.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Since another thread might close the socket, make sure after the
lock is acquired that the connection is still valid.
Add global declaration for completeness
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The Skype API calls the OnNotify callback in a separate thread: see
http://skype4py.sourceforge.net/doc/html/Skype4Py.utils.EventHandlingBase-class.html
Tested informally (chatting with another person for > 15 min)
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
socket for exceptional situations
|