| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Fix bug introduced in 68af0aad65d243e654866eac5a7cd728ee293aa0.
|
| |
|
|
|
|
|
| |
Instead of `/chlog on` we now have `/logging chat on`.
Instead of `/grlog on` we now have `/logging group on`.
Fix https://github.com/profanity-im/profanity/issues/1224
|
| |\
| |
| | |
Add (experimental) solarized-light theme
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This theme should (when finished) look well
with the solarized-light color scheme.
It is still very rough and needs a lot of polishing
but I will try to improve it when I find time.
Otherwise it might be start for someone
using solarized-light to improve it.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem is that in _handle_groupchat() we look for
STANZA_NS_STABLE_ID which will result in origin-id or stanza-id.
It seems like prosody servers send origin-id first, so this worked in
all my tests. But actually we cannot be sure of the order.
So far we stopped after the first element was found.
I only found xmpp_stanza_get_child_by_ns() and
xmpp_stanza_get_child_by_name() in libstrophe. But we need a combination
of both.
So I created stanza_get_child_by_name_and_ns() for Profanity. I need to
remember to upstream this to libstrophe later (if they really don't have
such a function).
Fix https://github.com/profanity-im/profanity/issues/1223
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Seems this actually never worked.
Now it does.
`/status set online "This is my text"`
`/status set away bye`
`/status set away`
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before we had `/online`, `/away`, `/dnd`, `/chat`, `/xa`.
These commands are no longer available.
We have `/status set online` etc now.
Before `/status` was used to get the status of a contact.
This now moved to `/status get`.
Regards https://github.com/profanity-im/profanity/issues/1116
|
| | |
|
| |
|
|
| |
and remove encwarn one.
|
| |
|
|
|
|
|
|
|
|
| |
`/invite <contact>` became `/invite send <contact>.
`/invites` became `/invite list`.
`/decline` became `/invite decline`.
Accept is still done via `/join`.
Regards https://github.com/profanity-im/profanity/issues/1116
|
| |
|
|
|
|
|
| |
Additionally to `/presence titlebar on` we now allow the setting via
/titlebar show|hide presence` since it's about the titlebar.
Regards https://github.com/profanity-im/profanity/issues/1116
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Additionally to `/resource titlebar on` we now allow the setting via
/titlebar show|hide resource` since it's about the titlebar.
But makes sense to have it in `/resource` too because there is
`/resource message on|off` too. And this one doesnt have an setting of
it's own.
Regards https://github.com/profanity-im/profanity/issues/1116
|
| |
|
|
|
|
| |
Instead of `/encwarn on|off` we now have `/titlebar show|hide encwarn`.
Regards https://github.com/profanity-im/profanity/issues/1116
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Programming with GNU
History](http://www.math.utah.edu/docs/info/hist_2.html) mentions
using_history().
Chet, maintainer of readline told me about it. (Thanks Chet!)
Seems like we need to call this so that the history offset is at the
right end of the list. I assume it's called in the linehandler
automatically.
Fix https://github.com/profanity-im/profanity/issues/200
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/200
This doesn't work yet. And I have no idea why.
Weird behaviour:
- start profanity
- type 'ASDF'
- ctrl+arrow down
-> text vanishes (like intended)
- arrow up
-> nothing happens (intended is that the last history item [ASDF]
appears)
- type 'ABC'
- press enter
- arrow up
-> ABC appears
- enter
- type 'UUU'
- ctrl+arrow down
- type 'ZZZ'
- enter
- arrow up
- ZZZ appears
- arrow up
- UUU appears
So in the latter case we added to history and deleted from the input
line and then immediately entered new text and pressed enter, to add
this to the history too.
When we do this the not sent text succesfully was stored in history.
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously we had `/tls show on|off` to manipulate the UI setting for
the title bar. To decide whether to show TLS info there or not.
This should go into `/titlebar`.
Now we have `/titlebar show|hide tls` for this.
Regards https://github.com/profanity-im/profanity/issues/1116
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
XEP-0184: Message Delivery Receipts, *requires* the id attribute.
Generally this is not the case.
For this reason the id was only present in the DeliveryReceipt struct
since it was only used for XEP-0184.
For https://github.com/profanity-im/profanity/issues/660 XEP-0313 MAM
and https://github.com/profanity-im/profanity/issues/805 XEP-0308 Last Message Correction
we will also need the id.
So in preparation for further work let's move the id to the general
ProfBuffEntry.
We will need to adapt code so that we actually always write the ID if we
receive one.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Profanity sends the same value for both. Other clients might not.
Safe both since we could need them later.
Once we implement Last Message Correction we will need the regular id.
If we override it with origin-id and another client chooses to not use
the same value for id and origin-id then we can't interpret the id sent
with the LMC request correctly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For OMEMO we had a list with our sent messages.
It was used so that we don't decrypt our own messages in MUCs that come
in via reflection.
Recently for https://github.com/profanity-im/profanity/pull/1209 we
started to use origin-id and use an algorithm so we can detect our own
sent messages via checking origin-id.
Profanity uses the same id for the message ID and origin-id.
With 06f300a42c4c627b6f1817bd48d92f083ffd9883 we added the
message_is_sent_by_us() function.
We implemented XEP-0359 this way to fix
https://github.com/profanity-im/profanity/issues/1201 so that we don't
log our own messages in MUCs twice.
We can now check whether the message was sent by us using this function
and can get rid of the list.
Probably we could also put many parts of the sv_ev_room_message()
function inside (else) part of `if (!(g_strcmp0(mynick,
message->jid->resourcepart) == 0 && message_is_sent_by_us(message))) {`.
Have to look more closely whether any of this needs to be run in case
the message actually comes from us.
|
| |\
| |
| | |
omemo: Check stanza names when iterating nodes
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some clients (eg. PSI) are sending the stanzas delimited by whitespace
text nodes, which will fail while looping through the <prekeys/>
children and also print weird errors when iterating through the <list/>
of devices.
When debugging this, I was looking at the XML of Gajim and PSI and first
was somehow confused why Profanity printed "OMEMO: received device
without ID" while the XML looked identical (minus the actual IDs and the
JIDs of course).
However, Gajim was sending the XML without whitespace nodes in between
and PSI did not, so for example the following (with the relevant
whitespace nodes marked with X):
<message type="headline" to="..." from="...">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items type="headline" node="eu.siacs.conversations.axolotl.devicelist">
<item id="...">
<list xmlns="eu.siacs.conversations.axolotl">
X <device id="..."/>
X <device id="..."/> X
</list>
</item>
</items>
</event>
<delay xmlns="urn:xmpp:delay" stamp="..." from="..."/>
</message>
... would result in three times the "OMEMO: received device without ID"
error, because we actually have three XML text nodes here that obviously
don't have an "id" attribute.
Now since the <list/> children above aren't really a problem and only
annoying, text nodes in the <prekeys/> stanza actually cause
omemo_start_device_session_handle_bundle to return failure.
I've fixed this by explicitly matching the stanza names we are
interested in, skipping everything else.
Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @devhell
|
| |
|
|
| |
Only define in case we built with GTK support.
|
| |
|
|
| |
gtk_init_check() already has that functionality.
|
| | |
|
| |\
| |
| | |
Paste command
|
| | |
| |
| |
| |
| |
| | |
For now we initialize gtk in tray_init().
Should maybe use a general function and check in tray_init and
clipboard_init whether gtk was already initialized.
|
| | |
| |
| |
| |
| |
| | |
New command `/paste` that sends the clipboard in MUC, Chat etc windows.
Fix https://github.com/profanity-im/profanity/issues/156
|
| | |
| |
| |
| | |
General GTK.
|
| |/
|
|
|
| |
Use GTK to take the text from the clipboard.
Add `/paste` command which pastes this text now to console window.
|
| |
|
|
| |
Fix build
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add resourcepart to the outgoing carbon that is logged, so we use the
correct filenames for MUC PMs.
Dont log incoming carbons of MUC PMs as a workaround to faulty server
behaviour.
See https://wiki.xmpp.org/web/Multi-Session_Nicks#Private_Messages under
'Client-side workaround behavior'.
Regards https://github.com/profanity-im/profanity/issues/1214
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Also we initialize mucuser properly.
Now in case of a carbon of a MUC PM we sv_ev_incoming_carbon() which
calls _sv_ev_incoming_plain() and then we log it via chat_log_msg_in()
in there.
But we also get the sv_ev_incoming_private_message() and call
chat_log_msg_in() in there too. So the incoming message get's logged
twice.
|
| |
|
|
|
|
|
|
|
|
| |
If I'm not mistaken MUC PMs have not been logged at all if there was no
other client sending carbons.
This should add MUC PM logging functionality.
We still need to make sure carbons log to the same file.
Regards https://github.com/profanity-im/profanity/issues/1214
|
| |
|
|
| |
It's in the def == NULL case. So will always be noop.
|
| |
|
|
|
|
| |
We have `/close` which does the same and more.
Regards https://github.com/profanity-im/profanity/issues/1116
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Let's use UUID to have a more random string then just 10 alphanumeric
values.
|
| |
|
|
|
|
|
|
| |
Change default themes text color
Using "default" instead of white makes the default better readable
when using a black/dark font on white/light background.
May fix #535
|
| | |
|