Gajim - 2024-10-28

Hey there ! I'm gonna ask the question most people must make at first, and I'm sorry, but... Is there a plan about supporting audio call in the future ? (and is it a money issue ? Is there something a non dev can do about it ?)

I wonder why some icons such as for the _Chat Details and Settings_ button vanish, when unfocusing Gajim's main window in the gtk4 branch.

> Hey there ! I'm gonna ask the question most people must make at first, and I'm sorry, but... Is there a plan about supporting audio call in the future ? (and is it a money issue ? Is there something a non dev can do about it ?) Last mention I found about audio call support goes back to a 2021 update about "clean up but mostly outdated for now") ↺

otyugh: there are open MRs but they depend on changes of third-party libraries, which need to be applied/accepted first ✏

meson, you should ask this kind of question in #gtk, they are helpful about how to debug such issues.

Link Mauve: is there a way to join the irc channel in Gajim bc of the registration?

Didn’t you do that yesterday?

I used Libera Chat's website

> otyugh: there are open MRs but they depend on changes of third-party libraries, which need to be applied/accepted first Does it means it's out of Conversation/Gajim's hand ? (dino use third party stuff then ?) (oh just found out in dependance libwebrtc-audio-processing1 -> okay webrtc is it then) ✏ ↺

Once you’ve started the join of the channel, you have to talk to xmpp:nickserv%25irc.libera.chat@irc.jabberfr.org and tell it your password, or use an ad-hoc command with xmpp:irc.libera.chat@irc.jabberfr.org to tell it your username and password.

Ah, I thought I gave you the JID yesterday.

But nothing is different whether you use their webchat or Gajim, the process is the same.

otyugh: audio calls between conversations and Dino should already work. You could always build the dependencies with your changes locally, but for a stable release depending on stable release of 3rd-party libs should be preferred.

Someone, not necessarily a Gajim maintainer, has to work with third party, to get changes upstream.

Oh it should ? I tried calling myself (using two different xmpp account using dino/gajim) and : 1) could only initiate a call from dino (that seemed to land instantly ? there is no pick up the phone thing ?) 2) nothing happened from gajim's viewpoint ✏

Oh it should ? I tried calling myself (using two different xmpp account using dino/gajim) and : 1) could only initiate a call from dino (that seemed to land instantly ? there is no pick up the phone thing ?) 2) nothing happened from gajim's viewpoint also I'm using sid, the versions should be pretty cutting edge ? ✏

otyugh, A/V calls between Conversations (Android) and Dino should work, Gajim is not compatible currently

Gajim and Dino should be compatible I think?

Oh it should ? I tried calling myself (using two different xmpp account using dino/gajim) and : 1) could only initiate a call from dino (that seemed to land instantly ? there is no pick up the phone thing ?) 2) nothing happened from gajim's viewpoint dino 0.4.4-1 and gajim 1.9.5 ✏

Dino can do both encrypted and unencrypted calls, and Gajim only unencrypted.

> Someone, not necessarily a Gajim maintainer, has to work with third party, to get changes upstream. Which was my initial push to ask "who should we turn to" if say, I wanted to redirect money to make it done (although I have no idea how pricey it'd be). ↺

And Conversations and web clients only encrypted.

Link Mauve, I see, thanks for the update!

otyugh: https://dev.gajim.org/gajim/gajim/-/merge_requests/995

You can try and contact the developer

It would be cool to have an XMPP client with Mumble integrated

meson, this is all documented in biboumi’s documentation, but it might differ per IRC services as all of them have their quirks.

theuae, Mumble is a different and incompatible protocol, you can have multi-protocol clients like Pidgin (I don’t know if it has a Mumble plugin though), or even gateways though. ✏

> I wonder why some icons such as for the _Chat Details and Settings_ button vanish, when unfocusing Gajim's main window in the gtk4 branch. meson: I'm having a look later

if you find a solution, I'd be interested to know ;)

cal0pteryx, it's related to the icon, changing the feather- to `system-users-symbolic` resolves the issue.

question is why

I see. I'll let you know :)

I'm aware that Mumble isn't related to XMPP, Link Mauve, I just like the idea of using one client for both services

theuae, check multi-protocol clients or gateways then, a pure XMPP client wouldn’t implement a second unrelated protocol when Jingle already does everything Mumble does and more.

> I see. I'll let you know :) it doesn't vanish actually, the stroke just gets the wrong color: light gray and light gray ;) ✏ ↺

> I see. I'll let you know :) it doesn't vanish actually, the stroke just gets the wrong color: light gray on light gray ;) ✏ ↺

I'm generally unfamiliar with XMPP voip solutions so do feel free to correct me if I'm wrong. I don't think that there's any one way of calling on XMPP that works across all clients/platforms. Hence, mumble

It seems like every client has their own slightly different implementation

theuae, you may have heard of Jitsi Meet or Zoom, both of which use XMPP for voice and video calls.

Oh really? That's interesting. I thought Jitsi used its own thing for the chatting, I guess not.

It uses the MUC protocol, like we are using here. :)

And does the call negociation over MUC as well.

Mumble is simple enough that you could make a plugin for Gajim most likely.

> it doesn't vanish actually, the stroke just gets the wrong color: light gray on light gray ;) In KDE Plasma Settings, the gtk theme is Adwaita. The gtk inspector reports wrongly Breeze on opening in Global/Settings. Changing it to Adwaita in the inspector leaves the UI unchanged therefore. Changing it to Breeze fixes the issue. ↺

meson: so a DE issue

> meson: so a DE issue I've changed the icon to `feather-user-symbolic` in the 1.9.5 gtk3 branch and the bug does not appear there ✏ ↺

testing the Gtk4 branch, the ctrl+N action is wayyyyyy slower than before

> meson: so a DE issue the only thing I can imagine is that it loads the color style for the SVG for the a dark theme variant on un-focus as it becomes white. I'm not sure if it is a DE issue. Aren't you on Tumbleweed with Plasma as well? ↺

rom1dep, at least for me performance hasn't changed.

meson: it also depends on svg format. I had to convert them to work in both light and dark mode, i.e. as symbolic icons.

rom1dep: hm, that shouldn't be the case. Would be interesting to see a performance profile. The new start chat dialog uses gtk's new listview for ++++performance ;)

yeah, it used to take, like, 3s, now it's more like 13

rom1dep: for startup, that is?

nope, to populate the list at ctrl+n

Yes, that's what I meant. And after that it's fluid?

it used to be very very bad, then lovetox to whom I complained several years ago added some pixmap (IIRC?) cache and it went to "unusable" to "meh"

after that it's fine

I'll have to dig up that profiler I used back then

https://github.com/benfred/py-spy IIRC

rom1dep: it's good to have this early feedback!

Let's wait for lovetox to appear. A profile might help though. I wonder if we already have a test for that

cal0pteryx: it actually uses the 32px png and _not_ the svg

and even if I rename the png to *.bak, it won't pick up the svg but shows a missing icon placeholder instead

Maybe the icon hasn't been converted correctly. Gtk offers a special tool to create symbolic png files

> and even if I rename the png to *.bak, it won't pick up the svg but shows a missing icon placeholder instead that might be due to the iconcache

I've removed the cache in `~/.cache/gajim/*` and now I got no avatars at all and the icon is still missing (with the renamed png) :>

* only my own avatar

No that's not what I meant. There is a special file in gajim/data/icons

But I'm not on a 🖥️ right now

> Let's wait for lovetox to appear. A profile might help though. I wonder if we already have a test for that apparently my python is too recent for the latest released py-spy, so I built py-spy from source, only to be met with "Collecting stack traces from native extensions (`--native`) is not supported on your platform." ↺

> But I'm not on a 🖥️ right now no problem, we can check that later :) not of utmost importance ↺

rom1dep, you can do `python -m cProfile -o prof.out launch.py` and then use e.g. snakeviz or whatever

meson: I like about py-spy that I can just fire it up whenever I am hitting a slow path

Emojis also look a bit weird on my gtk4 branch :)

https://share.conversations.im/meeson_/xr4EjKh0XRiqe2gm/Screenshot_20241028_185353.png

Emoji rendering is influenced by the gsk backend set on your machine. I had to override this for Windows for example as a temporary measure for a different issue. I think GSK_BACKEND is what it's called

Also depends on your gtk4 version

Looks like it's some gtk4 issue, Dino is having the same issue for some users ✏

on the same machine I don't have issues with Dino

It definitively is, but maybe it can be fixed by switching to another renderer

yes, GDK_BACKEND=wayland renders it wrong, GDK_BACKEND=x11 works - on Wayland

Lol

Gajim then runs as an.XWayland app: not sure where to report it now: to the kwin devs or to the gtk devs?

meson: https://dev.gajim.org/gajim/gajim/-/blob/gtk4/gajim/gtk/application.py#L223

funny, my emojis look alright, but the reaction bar shown on the screenshot is all over the place with apparently multiple buttons groups overlaping one another

> meson: https://dev.gajim.org/gajim/gajim/-/blob/gtk4/gajim/gtk/application.py#L223 with GSK_RENDERER=cairo no emojis are rendered for me anymore :) ↺

hello

https://upload.tamytro.org/upload/a3849b367f4dd4cedd5ad6f64afa7645b7d4f834/7bBxJMg3gKrr10pzA4P3AVhXSRtbuvLbY0Rvb7Z9/9e487b7c-4b1a-48f2-92f4-318b537341ca.png

> funny, my emojis look alright, but the reaction bar shown on the screenshot is all over the place with apparently multiple buttons groups overlaping one another ↑ ↺

oh, apparently I can't embed an image in a reply

> oh, apparently I can't embed an image in a reply There's an issue for that

https://dev.gajim.org/gajim/gajim/-/issues/11916

rom1dep, looks like your theme is missing a 'linked' class then ;) which theme do you use?

breeze, but apparently it renders fine on gtk3

just used ctrl+shift+i to switch it to adwaita and indeed, it's fine then

> breeze, but apparently it renders fine on gtk3 can confirm the issue on Breeze and that it works fine with Adwaita ↺

https://discuss.kde.org/t/gtk4-apps-don-t-follow-breeze-theme/2969/2

> The Breeze GTK theme does support GTK 4 apps in general, but not the ones using the libadwaita styling. It’s possible that it could in the future, but this hasn’t been done yet because the GNOME folks have made it hard, and libadwaita is yet another moving target we would have to keep on top of. from Jul 2023, but it seems the situation hasn't changed much ✏

never mind I head "does not" ...

rom1dep, I think this needs to be reported to the kde devs with a minimal example code

. ✏

how is this relevant? we dont use libadwaita or?

lovetox: I am for too long in front of the screen, I read the sentence as 'it doesnt support gtk4' accidentally, sorry. I will better shut down now

just a last thing I've noticed: avatars in the group chat participant list are rendered blurry with a scaling of 2x:

https://share.conversations.im/meeson_/Pbz6wzqNQ3d2vVBA/Screenshot_20241028_210316.png

yes, that's a known issue. if we supply a scale factor, they are scaled, but cut off

treeviews are deprecated, and I think we can live with that until it has been replaced

Also one could consider moving away from cairo to snapshot texture rendering later

Yeah in gtk5 all cell renderers will go away

Gtk5 already? that sounds exhausting

there are no plans for gtk5 to my knowledge

https://docs.gtk.org/gtk4/migrating-4to5.html

rom1dep: ^ No idea of any time plan

looks to me just like a list whats deprecated

everything is titles "is going away"

no work has been done to actually make it going away

also the first sentence reads > GTK 5 does not exist yet, so we cannot be entirely sure what will be involved in a migration

> GTK5 ? > > We need to open a .90 branch to do things that would break the APIs that we have deprecated now (...) > suggestion is to open a 4.90 development branch after 4.12. That would put it towards the end of this year, and 3 years after the 4.0 release, which seems reasonable. Looks like this indeed hasn't happened in 2023 and not in 2024 :P https://blog.gtk.org/2023/02/09/updates-from-inside-gtk/ ✏

removing things is not a reason to release a new major version

they first need to work on the things for which users want to upgrade

that document is a WIP migration changelog. it will get filled while gtk5 is being developed. it's like we would start a changelog for gajim 3.0

Sure it's just a collection of ideas in what directions they want to go. > Yeah in gtk5 all cell renderers will go away I should have phrased this better and added a "likely" or "could"