Gajim - 2024-03-24

> also which one is the last version without workspaces? Ge0rG: 1.3.3 (workspaces were introduced in 1.4.0) https://gajim.org/post/2022-05-11-gajim-1.4.0-released/ https://gajim.org/post/2022-04-30-development-news-april/

intelfx, yeah on first look that would seem more appropriate

intelfx, if you see such small refactor work, please make a separate MR for that

and rebase your MR after its merged

lovetox pushed 1 commits to branch python-nbxmpp/master feat: Add XEP-0215 namespace - https://dev.gajim.org/gajim/python-nbxmpp/-/commit/6e994095017848cf9601bb81027454ad8808035c

Spam

Spam

Spam

i am not clicking that stuff mister stranger

Spam

Spam

Spam

lovetox, yep for now I'm working in my branch but I'll split everything into separate MRs of course

intelfx: great to see you are still working on this

<3

222m5: thanks very much!

just so people know, in Gajim 1.3 when it was multi window based, we had a option to have a window mode, where groupchats and single chats were separated into different windows, when we did design the 1.4 one window design, we thought its a useful feature to group certain chats, especially so people which used this window mode could get the same functionality

so a workspace is simply a grouping of chats

you dont need to use it if you dont want to, then you simply have only one group

They get in the way tho. The pencil button which makes me (and not only me as discussed here) think it's the "write message" button. Why is the "My Workspace" label so big, do people who use them need to be constantly told which one it is, and in such big letters?

chud: the button has already been changed, the next version will provide a different solution. And the label size is just your oppinion ;)

The button is also just an opinion

also it has nothing to do with the question "why are there workspaces"

though i thought we could use a better icon as default

and maybe the default Worspace should be called "Chats"

> The button is also just an opinion This was a valid point is what I wanted to say. The button is now only shown when hovering the title, which makes the context clearer ↺

I'm not saying they shouldn't be there, but it's probably best if an obscure, unique feature you don't encounter in any popular messenger nowadays, doesn't get in the way. Yes, calling it chats would be a good idea imo

yeah if we name it Chats, nobody will ever ask anymore what a workspace is

:d

they would only discover if they click the + button

yes

actually, pencil would probably be a better icon for a new message than a plus

because now you have two pluses and I think to a new user it may not be obvious which plus does which

but the + opens a menu, which is not only for writing message

someday i would want some universal search bar always visible

>but the + opens a menu, which is not only for writing message oh, right

wurstsalat pushed 1 commits to branch gajim/master fix: Catch errors when trying to store pasted image - https://dev.gajim.org/gajim/gajim/-/commit/28c4edc45ef586925859d51acc2d886392536dc9

can someone help me debug a thing that I did with async code in nbxmpp guts? 🙃

I tried to port nbxmpp's iq_request_task() to gajim here: https://dev.gajim.org/gajim/gajim/-/merge_requests/995/diffs?commit_id=5d7348d1d409b93dfdce01fa795836db917cbddf

this, in turn, was used to send the XEP-0215 request from gajim Discovery module: https://dev.gajim.org/gajim/gajim/-/merge_requests/995/diffs?commit_id=4e80e1bc9ac400a3ed3cfec5f7a969ddca535e3c#604c873585e1777d16c20ff7606d35fe19081c75_182_256

(it should probably be lifted to nbxmpp, but for now I guess it lives here)

but the response never arrives

so you are saying the request is sent but the server never answers?

so not a problem with your code?

I'm most likely using the async machinery incorrectly

but this would be easy to check, open the xml console, and see if xml is sent to the server

but yeah all iq requests should be added to nbxmpp into some module

why not move the code there? i see no problem to merging it fast, if thats your reason to add it to Gajim

I was just prototyping, easier to write all code in one place

OH, I just missed my debug print for some reason when grepping through the logs

I blame tmux :D

nevermind, everything works as expected (what I wrote is still broken, but for a different reason entirely)

I'll move it to nbxmpp as soon as I confirm the thing works at all

and thanks, I did not know about the xml console

to be honest i never thought to use iq_request_task in Gajim

so this code was not designed to use by other applications

how does Gajim deal with similar needs?

does it just fire off iq stanzas and declare module-level handlers for responses? ✏

it does not, all iq requests are implemented in nbxmpp

I think at least jingle does its own?

ah yeah .. i forgot jingle :D

I think back when all the modules were refactored, jingle was the only one left in gajim

you can use client.send_stanza()

it has a callback arg, which notifies you if the iq response comes

but the callback arg is also not forwarded from gajim to the nbxmpp client, instance, so you need to call the nbxmpp client instance yourself, or add the callback arg to gajims client class

yeah, jingle uses nbxmpp.Client's send()

but it does not use per-stanza callbacks at all

yes its super old code

it has a module-level handler and maintains a dict of iq ids itself

hm, I'm thinking about moving this thing to nbxmpp and there's a slight issue

so the server sends us a response directly to our iq request, but it can also push new updates voluntarily

and I'd like to reuse the parser

but if the parser gets moved to nbxmpp, how would I handle the pushes?

(this is XEP-0215)

checkout the blocking.py module in nbxmpp

this xep has also iq pushes

you parse everything in nbxmpp into some dataclass struct

and attach it to the properties struct

then you simply define in gajim a stanza handler for the xep namespace and iq

and access there the properties struct

the idea how this works is, that nbxmpp also creates a stanza handler but with a much lower priority

so it gets the iq, parses everything into some dataclass, and then passes the event on with the added info

later gajim gets it

aha, I see

but I do not see where the dataclass is constructed at all?

the BlockingProperties in this case

in _process_blocking_push()

every stanzahandler callback gets a properites struct passed, and you can simply assign whatever you want to this struct

it gets passed on to every handler afterwards

ah so it is not really an instance of `class BlockingProperties` but just a generic something?

its a subclass of IqProperties

which is simple a class with a lot of attributes

nothing special, its basically a place where every handler can attach info to

so the next handler can see it

dont know why i added a subclass there .. have to look

I see, so it _is_ an IqProperties then

this .. is bullshit, i think i did that only for type hints

IqPropertiesBase is never instantiated

it never gets really instantiated

yep

@dataclass class IqProperties:

that is the real thing

yep I just realized that

its all fucked and a hack on top of some hack

so the type hints are wrong

dont question the sense in all that :D

i planned to rewrite the whole thing a year ago, but .. it kind a works ok .. so other things always had priority

okay I'll do something similar then

> i planned to rewrite the whole thing a year ago, but .. it kind a works ok .. so other things always had priority yeah ain't that the truth :D ↺

thanks, it'd have likely taken me several hours to untangle this by myself ✏

and iq_request_task was invented so i can get the result of an iq inline without callback

mostly for pubsub stuff, where you publish, then it fails, then you pull config, then you change config, then you publish again

like 4-5 iq requests until you published something

if you do this all with callbacks, its callback hell

yeah, callbacks are evil

I think the entire world had realized that a while ago :D so we have async/await now

thats basically the same thing python does with its asyncio stuff, but they have more syntax sugar

yup exactly

I guess nbxmpp predates async/await?

no, we cant use it because we dont use the python main loop

we use the GLib mainloop, and it has no bindings to the python main loop

and we need to use the GLib mainloop because GTK only works with the GLib mainloop

hmm, but can't you use async/await with any eventloop if you do the glue code yourself

but that glue code does not exist

yeah

and smarter people then me failed :)

perhaps I'm not smart enough to see the problem... doesn't async def give you the same generator as you would've written by hand

then you can manually push the data with send, just like Task does already ✏

maybe, i also wondered if some of the stuff i build there is not somewhere in python already

but never bothered to check

i have to say im not a huge fan of the whole async/await stuff, it makes some thing easier, but if the whole application is littered with it, for me its another kind of hell :D

yep, it's pervasive

perhaps you could combine old-style functions and callbacks with async/await where it makes things easier

anyhow, all that stuff is something for another day :D

Gajim and nbxmpp is like this really messy thing, that you want to clean up, and then you clean and clean, and 5 years go by and you look at the code from 5 years ago and thing, hm i need to clean this up again :D

I was experimenting with just that - async/await on the glib event loop in gajim for jingle... https://dev.gajim.org/wusspuss/gajim/-/blob/master/gajim/common/jingle_bells/jingle_av_session.py?ref_type=heads#L262 Combining async/await with existing callbacks-based code is awkward, but I think not as awkward as adding more callbacks.

That branch now supports video calls and runs on windows btw

I achieved async/await support by implementing very simplistic Task and Future like those in asyncio. It would've been nicer if the asyncio evloop was actually integrated with that of glib, but it's been years and not implemntation came about that would at least support windows

while my approach gives much much more limited concurrency primitives than those of asyncio/trio, it takes no effort whatsoever to support different platforms, it exists a level above that basically ✏

looks interesting, i always thought you need to use the even loop to use the syntactic sugar async/await

but seems thats not the case

well of course it can't depend on an event loop if it's just syntactic sugar 🙂

the only thing sometimes would be nice, is to fire and wait for 2-3 iqs in a row

Python did overcomplicate coroutines imho compared to Tcl. You can't really use them bare, send() stuff is awkward

so i dont think we need any special concurrency primitives

>the only thing sometimes would be nice, is to fire and wait for 2-3 iqs in a row gather() already takes care of that and I already implemented that in a couple of hours

so like what would be the requirements to actually get this thing merged I haven't implemented dtmf yet, is that a show stopper? Other than that it lacks the option to start and stop the video during the call. But it otherwise works with both Dino and Conversations. I figure a proper flatpak would be one requirement, a windows build script I hope can wait (I have run it on windows successfully, but had to install deps by hand).

>gather() already takes care of that and I already implemented that in a couple of hours oh you said in a row, yeah that's not gather that's just await

Honestly this is mostly an experiment to even see how async/await would play along with an existing, cb-based codebase https://conference.gajim.org:5281/pastebin/aa18cac5-bbf3-4432-92a8-cdd004fc0901

https://draugr.de/upload/00f530bb49b4e1685114d28f8bb6fb44b2fcbc2f/uezVOqQ81o9YkGZGrkihRlakFBGnuxUHF2Ru8KEC/Screenshot_at_2024-03-24_15-08-27.png

was the original video call window already this fugly or did I screw it up ✏

I don't think I changed much layout-wise, but the video widget is instantiated differently so maybe some setting is off for it

i dont know, i never saw the video call window

>may look simple in writing, with state machines they just turn into a huge mess not to mention... try unit testing the state machine stuff... like when you want to wait for an event and each wait turns into a callback, and instead of top-to-bottom human writing it turn into boustrophedon or smth

i would say start with making an MR

yeah i believe that it definitly has some pros, but like everything it also has cons, one beeing that i need to understand the near 1k loc async primitives module

libdatachannel seems not be packaged widley, i would say this is definitly a topic

It is packaged for archlinux at least and it works on windows unlike what gajim currently has. It's easy to build also (a single self contained repo basically, no extra deps). ✏

> yeah i believe that it definitly has some pros, but like everything it also has cons, one beeing that i need to understand the near 1k loc async primitives module It's only 500 loc, of which I think 1/3 is copypaste from asyncio and another 1/3 is lose adaptation. But yes may be tricky to understand as these ideas in general are rather new. I also got unhinged there and implemented a bit of "structured concurrency", i.e. nurseries, which I think only came about in asyncio like a release or two ago ↺

I did hold back from using python 3.11 language futures (exception groups). If I hadn't, it'd probably be yet shorter.

also the adhoc_async stuff could in principle just be another library. In an ideal world, we'd get asyncio-glib integration, but in years and years not even one implementation of that has popped up that so much as supported windows. Also , I think my thing may actually be less error prone, or more like the errors won't be as severe. Event loop integration if you actually look into it can be exceptionally tricky especially in edge cases, and harder to debug. ✏

My thing deals with higher levels of GLib, which are closer to "interface" than to "internals", so I would also bet on my approach when it comes to future version compatibility (gnome guys love to break interface, I can only imagine how much they rework the internals) ✏

My thing deals with higher levels of GLib, which are closer to "interface" than to "internals", so I would also bet on my approach (as compared to event loop integration) when it comes to future version compatibility (gnome guys love to break interface, I can only imagine how much they rework the internals) ✏

> I also got unhinged there and implemented a bit of "structured concurrency", i.e. nurseries, which I think only came about in asyncio like a release or two ago But I think it suits the case: a session is in a way comprised of several parallel routines (like xmpp singlaling, playing the contents, etc), which in turn may spawn new routines for their need. With nurseries, none will be left dangling, and I make extra sure of it in the unit tests ✏

i agree, im not waiting for a event loop integration, it seems not enough people need this or it would already be here

for building on windows, the way to go would be to add the package to msys

https://www.msys2.org/wiki/Creating-Packages/

they use pacman, and arch style package files, so it should not be a big challenge?

i definitly dont want to build this in our CI, this would be one more additional thing that can break

I already made a draft libdatachannel pkgbuild for msys2

https://github.com/wusspuss/libdatachannel-mingw-pkgbuild/blob/main/PKGBUILD

that's a lot of messages everyone's life just flashed in front of me

testing windows is a huge PITA for me though as I only have it in qemu and it's absurdly slow. And installing it on the host... oh boy, having to shrink the linux partition, repair grub etc etc, I'm not eager to waste a day on just that

chud, Don't do that chud

upgrade your hardware

woah, does this do a/v on windows or am I misunderstanding

yes

damn, I daily drive windows so I might be able to assist

(wrt packaging)

I also made a draft pkgbuild for libdatachannel python bindings https://github.com/wusspuss/libdatachannel-python-mingw-pkgbuild/blob/master/PKGBUILD it seems on windows they have to be installed via the msys package rather than pip because of cffi/toolchain stuff

so basically to get them to work just libdatachannel and libdatachanel-python need to be packaged into the windows distribution if I'm not mistaken. and it has to be built from my branch ofc ✏

if you checked at it works at all on windows, i would concentrate on linux, its unlikely that any stuff that does not work on windows will be fixable in Gajim code

im saying this under the assumption, that you said before that you tested a/v on windows and it works

yes it did. But only made like two two or three test calls on windows so there may be pitfalls I'm not aware of. On linux I have actually used it in practice to call ppl