Gajim - 2023-10-07

Philipp Hörist pushed 3 commits to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: *af39fc35* < https://dev.gajim.org/gajim/gajim/-/commit/af39fc355654dcbffe135c4442b27f037f302638 > new: Add icons for various gateways *43488704* < https://dev.gajim.org/gajim/gajim/-/commit/43488704fc1994201c572a8616985baf11050e89 > refactor: Improve determining gateway type and icon *1eed2ab9* < https://dev.gajim.org/gajim/gajim/-/commit/1eed2ab92bb426fde9726e6aabd2b52910958fbd > cq: Remove unused variable

Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: *03849456* < https://dev.gajim.org/gajim/gajim/-/commit/038494564810c71ffb3d37eae911144ac2d34ca9 > other: Remove obsolete icons

Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: *16058093* < https://dev.gajim.org/gajim/gajim/-/commit/16058093a096122b8dad87ac0d56dbc7c60fa9e0 > refactor: Rename icons for consistency

Given that gajim's calls don't work with modern clients anyway, if I were to make an MR that brings dtls-rtp but disables video calls, would it be considered? I do plan on bringing dtls-rtpd video calls too, eventually, but I think people would value getting working audio-only calls faster over keeping the non-working video calls for longer. ✏

I'm asking because I found it much simpler to swap out farstream for a more modern rtc library which isn't integrated with gstreamer, so playback takes more effort to get to work. But on the bright side we can then no longer depend on libnice, which will make calls support on windows closer, or maybe even readily possible if we're lucky.

chud: which rtc library do you use?

libdatachannel. It's compatible with windows, has its own libnice replacement. As lightweight as it gets I think. ✏

yes chud, nobody uses gajim for video calls, im not aware that anyone got this working

it was also never adapted for the new GUI since 1.4

so in my opinion we can throw away this code anyway

👍️

André pushed 1 commit to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: *5964c85c* < https://dev.gajim.org/gajim/gajim/-/commit/5964c85ca7ecc93ab6e18ba54272e475205f7b39 > chore: Flatpak: Update runtime + dependencies

André pushed 1 commit to branch _refs/heads/master_ of _gajim-plugins_ < https://dev.gajim.org/gajim/gajim-plugins >: *7675a98f* < https://dev.gajim.org/gajim/gajim-plugins/-/commit/7675a98f4a88bad0619450f03c01202b7ac18b6d > Flatpak: Update runtime + dependencies

Is there any particular motivation behind creating ged instead of making use of gobject signals which are already there? Is it just historical? cal0pteryx ✏

partly historical, partly because its not very flexible

and to write code to notify some other subscribers is like 100 lines of code

specifically for the ged module the requirement was to notify subscribers in a specific order, depending on priorities

> and to write code to notify some other subscribers is like 100 lines of code wdym? It's just instance.emit('signal', args) ↺

> specifically for the ged module the requirement was to notify subscribers in a specific order, depending on priorities I see ↺

altough gobject signal have connect_after, that may not be as flexible I guess

it also misses methods to efficiently disconnect stuff

it is expected you save a integer and carry it around until you disconnect with it

there are some methods to do it differently, but i never got them working with python

i think they simply not work with bindings

also you cannot pass weakref methods as callbacks

though the ged module is ancient

for objects we currently use gajim.common.helpers.Observable

We usually use GObject signals, if we inherit from some Gtk Widget, and extend it with more signals

but yeah there are a bunch of different notify approaches in Gajim

probably 3+

use the one that does the job the best :)

> Is there any particular motivation behind creating ged instead of making use of gobject signals which are already there? Is it just historical? cal0pteryx chud: fine with me :) nice if we get audio working with Conversations (and on Win) ↺