Age | Commit message (Collapse) | Author |
|
- Added as always new theming variables:
CHAR_ROSTER_MOOD, CHAR_ROSTER_ACTIVITY (a SNOWMAN!)
COLOR_ROSTER_MOOD, COLOR_ROSTER_ACTIVITY
- Added two new notification types in Theme.INFO_COLORS (mood/activity)
- Added new configuration options:
display_mood/activity/tune_notifications (those can be set for a
specific JID)
enable_user_tune/nick/activity/mood
- Added /activity and /mood commands, with completions
- Moved the old /activity to /last_activity
- Details are show in the ContactInfoWin if there is room, or with "i"
on a contact in the roster.
|
|
- add a use_pep_nick boolean option
- use it as a nickname for roster contacts, but it does not
supercede the user-defined handle
- send a <nick/> at the beginning of a normal chat
- not implemented in MUC (wontfix)
|
|
|
|
- Add new theming options
- Show the tune in the roster (both in contact line and infowin)
- add an option to show tunes as info messages
|
|
|
|
|
|
- Add a “prepend” attribute to the Line tuple
I’m not sure of the impact of this on performance (we parse the message
yet another time)
|
|
(add a new theming option, too)
|
|
Also:
- Add get_conversation_messages() to PluginAPI
- Make plugins_autoload colon-separated instead of space-separated
(for consistency)
- Replace a JID() with a safeJID() in the uptime plugin
|
|
- add methods related to timed events to the PluginAPI
- remove parse_command_args_to_alias because str.format does that, and
better
→ update the alias plugin
|
|
|
|
- Try to reduce the use of the “core” object in the plugins
- New “api” member for each BasePlugin which is a wrapper around
the unique PluginAPI object. (instead of having the methods
directly in BasePlugin and then calling the PluginManager)
- Documented methods with rst (for sphinx)
|
|
(THE NAMESPACE WAS NOT PRESENT ANYMORE)
|
|
|
|
for consistency
|
|
|
|
|
|
|
|
(also move replace_key_with_bound() to core.py, to prevent having
common.py depending of config.py)
|
|
|
|
- Add the theming options COLOR_ROSTER_ERROR, CHAR_ROSTER_ERRROR, and
CHAR_ROSTER_ASKED
|
|
|
|
|
|
|
|
|
|
|
|
- remove the help message for people still using the old custom
sleekxmpp repo
|
|
- reload the config/theme with SIGUSR1
- quit properly with SIGHUP/SIGTERM
|
|
- Prevent correction of delayed messages
- Prevent correction of messages by someone else in a MUC (and in a
private tab)
- Messages with unauthorized corrections (above) or wrong message id
will be displayed as normal messages
TODO: restrict the corrections to the same fullJID (only in direct
"normal" conversations, because we can know in private an muc tabs, via
the User object)
|
|
|
|
(if the room was not joined)
|
|
(like in weechat)
|
|
|
|
(add a defaultdict to keep the folded state in each group)
|
|
|
|
M-d and M-c become M-D and M-C
|
|
when no message has been sent yet
|
|
|
|
|
|
|
|
This makes it easy to review all the highlights after the separator was
placed, using M-h, M-n, M-n, M-n…
We just add a counter of highlights which is incremented each time there’s
an hl, and set to zero when we reset the separator. We use that counter to
set hl_pos when we scroll to the separator.
|
|
|
|
|
|
|
|
|
|
With a few specific behaviours: When manually opening a conversation with a
bare jid, we open a normal conversation that follows the XEP (locked and
unlocked accordingly). If the user manually opens a conversation with a
fulljid (by selecting a specific resource in the roster, or by specifying a
fulljid to the /message command), we open a special tab that doesn’t follow
the XEP (it is always locked to the same resource, and cannot be unlocked).
When a message is received, unless a special tab has been manually opened by
the other with that specific resource, we always send the messages to a uniq
normal tab, unlocking or locking it according to the XEP.
This means that only one tab can be opened with a given contact, unless the
user specifically chooses to open a special tab for a specific resource.
fixes #2159
|
|
- because it is an heavy operation, and it is useless, since the lines
only change when the width changes.
|
|
|
|
|
|
- The code is more understandable
- The number of iterations may have slightly increased
- Less things are done inside the lock, so the overall experience should
be smoother
|