Gajim - 2024-05-09

cal0pteryx: I've rebased and factored out the widget. There's more to be done though :) Thanks for the feedback you had provided so far.

meson, thanks a lot, will have a look again!

I think I should try to add some Tests at some point for both the recorder, player and visualizer.

KDE uses some nice auto UI tests with selenium for their projects.

cal0pteryx sqlalchemy > 2 is in Debian experimental since almost one year :-) Just: `echo "deb https://deb.debian.org/debian/ experimental main" | sudo tee /etc/apt/sources.list.d/experimental.list`

debacle, cool! :)

Also, it looks like it can be moved to Debian unstable (and then testing) soon. There are still one or two fixes missing in other packages, IIRC.

Only a year to move a package that's readily available on pip

nobody is forced to use Debian, but it's Debian's policy to "move slow" in order to provide stable packages

lovetox: where inside nbxmpp do you want adhoc_async and sdp?

async a module in the root folder

sdp, maybe, module/jingle/util.py? or sdp.py what you think fits best, i cant remember right now what everything is in that module

There's no module/jingle in nbxmpp. There's no mention of jingle in nbxmpp other than the namespace alias.

yes, i think its worth to add it, jingle is a big topic in xmpp, its very likely more gets added there in the future

On master, when I select multiple messages and click on copy or delete it only takes the message into account, for which the context menu is opened. Regression?

what do you mean by "or"

copy works as exepcted for me

multiple delete was never a feature

meson, can you describe that workflow? I think this is something unintended? you select more than one message and then click the menu?

because only the overlay box is what works for multiple messages, not the menu

Here's a screenshot, which hopefully explains it better:

https://share.conversations.im/meeson_/W6Y5Ai5E5jQExvda/Screenshot_20240509_210508.png

I thought I could use the context menu now to act on all selected messages. ✏

nope you cant ✏

though multiple delete would be probably a nice feature

> though multiple delete would be probably a nice feature Indeed! ✏ ↺

ah you tried to add a reply in a correction

yes :)

and it worked nicely :)

it's really great

iirc I could copy (ctrl + c) and paste multiple selected messages somewhere before or what was its purpose? because right now it doesn't copy anything for me when I try it.

maybe another gtk / kde bug

do you copy via menu?

meson, do you actually see the overlay with the two buttons?

the only way this worked until now was, when you click the copy button on the overlay

the context menu? or is there another menu I didn't see?

ahh

sorry ...

just wanted to ask :D

too obvious. 🙈️

yeah tough, we could disable menu entries that will not work for multiple message

dont know if we can easily detect if we are in multi message mode

I think it's fine, it could still be useful and it's probably just me who didn't see the bold blue button in front of his nose ✏

do you plan to add a thumbnail when replying to a picture, so it becomes clearer which one is meant w/o clicking on it?

right now it's just a symbolic icon.

a icon and the filename

when you click you jump to the picture

if its so long ago that its not visible anymore in the chat

we thought about it .. but i dont think we had plans for now

i would think about this if we get more feedback from users, and its a issue for many people

we also dont show the whole text message in a reply

so its not evident why we would need to show a whole picture

If there are only a few pictures it's irrelevant, but if there are many it would definitely enhance the UX. E.g. we have a `Fotografie` muc (xmpp:fotografie@room.pix-art.de?join), where many photos are shared and it would come in handy if you knew to which one someone replied.

Cheogram shows a picture icon as well, not the original preview

as said, we are open to it, but lets remember that only a few people even have tried replies in Gajim

sure :) I'm just thinking filename might not be too useful to identify a picture. `DSC_1234.jpg` or `Pixel_20240509_2043.jpg` or even worse if omemo is in play `252o352jt2to-3sdf25-j3o2jo24.jpg`.

why cant the filename be preserved if the files are encrypted anyway? just decrypt the filename when the file is downloaded

amogus, iirc there's a new version of omemo which allows that by sending encrypted metadata along, but it hasn't been adopted yet.

yeah it would be useful to at least have an option depending on the context, for example sometimes you would want the name to be randomized, other times you dont

why would you want to have the name randomized if you send the actual content?

because sometimes the filename contains personal information while the content doesnt, for example screenshots often have the date and time they were taken in the filename, and may be bad if anonymity is required

amogus, fair. Indeed Gajim keeps the original filename: https://dev.gajim.org/gajim/gajim/-/issues/11470 :P but Conversation doesn't anymore since 2020 or so

i'm in debug in gajim. I see that debugger never comes to is_joined state in couple conferences. But in nbxmpp everithing is ok. It receives a good data from server... Where to set breakpoint to understand what is going on?

you would first need to tell us, what the problem is you have

lovetox: I created an mr with adhoc_async to nbxmpp as requested https://dev.gajim.org/gajim/python-nbxmpp/-/merge_requests/88

thanks

Also out of curiosity I counted my locs and it's just 1653 under jingle_bells, not 5k

Farstream has 46k while libdatachannel only 27k ✏

you can see the loc in the merge request

under the changes tab

one thing please, in the whole discussion it was never about farstream, its not farstream vs datachannel, as i understood it they are not doing the same thing, farstream is not using webrtc. Its just one transport, and we can support multiple. Jingle is the framework that lets clients negotiate what to use. Thats why saying we dont need any kind of abstraction in Gajim feels wrong. I can guarantee you that not the whole xmpp ecosystem will use webrtc datachannels, if i later want to add a new transport, i dont want to reimplement the whole session negotiation logic and so on ..

i thought about the whole thing, and i have nothing against the async stuff, i need to look into it to better understand it but i think its better than the non-async generator stuff we have today in nbxmpp for some IQ workflows. What i still cant really see is how the separation between nbxmpp and Gajim can be uphold, nbxmpp should do all tasks that are related to the protocol, so we will need to think how that can be achieved. The code that really does the jingle negotiation does look not that big, if we can move more of it to nbxmpp, and find a good separation, i think i can live without that jingle framework stuff for now, at least until we implement more other stuff from jingle.

cal0pteryx, just noticed that jumping to a deleted message via a reply results in an empty message screen with "Scroll up to load more chat history…" text. I guess the reference message in the reply should instead be discarded too? ✏

hm no, it should simply not jump anywhere

and the text in the reply box should probably be updated to, "reference to unknown message" or something

that's basically what I suggested

i thought you meant hiding that the contact did try to reply to a message

Sorry I had described it badly

The same should then also happen if you delete a message after you hit reply: now the reference is still shown but vanishes (locally) when you send the message

اصبح هذا التطبيق مملا ولا احد يستخدمه ابدا لاينفع ابدا انه تطبيق مخترق وغير امن ولايفي بالغرض

wurstsalat pushed 1 commits to branch gajim/master fix: ServerInfo: Don't fail if there is no certificate - https://dev.gajim.org/gajim/gajim/-/commit/5d8a103df56b5a5c76a7518a510f9d5f015e88e0

33777, this chat is english only. If you want to complain, please do so in english :)

heh