Gajim - 2024-07-01

hello

i need a spammer

Hi. I recently upgraded from a very old gajim version (1.3.X) to v1.8.4 (newest one I can get from my repo). I am kind of annoyed by the opening behavior when I have unread messages. I was used to the bahaviour to only need one click on the tray icon to be able to read the new message said icon indicates. Also it was great to be able to click that icon a few times to get rid of it if I had already read all new messages on another device. Now I've searched for the topic and found issue 11109 on your git, where you explained that this was removed more or less for privacy reasons (i.e. you dont want your chat partner to see that you've read the message yet), but imho that is not exactly a valid reason, as it tries to solve a social problem technically. Besides that: If I dont want the other side to see when I have read its message, I could just disable read receipts. Therefore I've got the following question: Is there any setting or toggle in the ACE I might have overlooked that restores the old behaviour, which - in my opinion - was a much better UX? If not: Are there any plans to implement one?

dev: the old behavior opened pending messages in an arbitrary order, which adds an element of surprise, which is nothing you want in a GUI. Now, a click on the tray icon opens the main window, where you can see unread counters, which allow you to make a decision on what to read. For your second point: you can right click on a workspace (left bar) an select "Mark all as read"

> Now, a click on the tray icon opens the main window... Only if I disable _use_libappindicator_ in ACE, otherwise even that takes two clicks. (I know the reasoning behind it, as it was part of the same issue.) Regarding the surprise: The order could simply follow the order of the incomming messages, i.e. showing the message first which was sendt first. "Mark all as read" is better than having to open up every chat manually. Thanks for the hint, I didnt notice that option yet. Imho its still more cumbersome than the old behaviour, though.

The shortcomings of libappindicator and gtk deprecating gtk.statusicon are sadly nothing gajim can change. The decision to not have the status icon open random chats on click was a deliberate one though. It's now initially two clicks (one opens gajim's window, the second click opens the chat you actually want to see). From there on, it's one click per chat (or "mark all as read"). So effectively it's one click more in the whole workflow and no surprises anymore.

lovetox, Debian nightly installed OK this morning, thanks

I wonder when the package for Gajim of Arch Linux be updated.

sch: Version 1.9.1 was submitted to staging yesterday, so it should not be too long now.

Great! Thank you zak!

Nothing new for Fedora unfortunately. protobuf is still not updated. There is a bug entry for Gajim, saying it will be orphaned in 7+ weeks. https://bugzilla.redhat.com/show_bug.cgi?id=2291527

> 2024-07-01T08:28:47Z - cal0pteryx: > The shortcomings of libappindicator and gtk deprecating gtk.statusicon are sadly nothing gajim can change. > The decision to not have the status icon open random chats on click was a deliberate one though. It's now initially two clicks (one opens gajim's window, the second click opens the chat you actually want to see). From there on, it's one click per chat (or "mark all as read"). So effectively it's one click more in the whole workflow and no surprises anymore. Gajim could join other GTK+-based software in efforts of making a GTK+ fork finally, free from GNOME madness. This should have happened a decade ago. I believe it would require less efforts than keeping up with their breaking changes and ideological decisions. ↺

bodqhrohro: that's your opinion and I don't share it

There is nothing stopping lib indicator to add that click action, I think they have a feature request for it, but seems nobody has time

RAINBOW text, but nobody sees it.

Of course I do.

Link Mauve: good for you.

I'm running gajim 1.8.4 and it can no longer remember my password. I have keyring stuff installed but it seems to ignore it. Any ideas?

Enable debug logging and look for errors

Is it ok that I see less of chat history in Gajim than in Conversations (Android)? Specifically, in this public group: xmpp:modernxmpp@rooms.modernxmpp.org?join, I only see the history since Tue 06/11/2024. But in Conversations app I can scroll indefinitely, e. g. reach 2023 and cannot reach the end. Is it like a configurable feature?

No, we don't support requesting history over a day on first join

After first join you need to set the sync threshold in the chat settings to your liking

So "No threshold" should make whole history reachable?

https://share.conversations.im/belkka/NKOjnUaf3cT1BdRt/cf01da6a-2908-4ab4-859c-4f8ef24f7169.png

After setting this value, the Gajim's UI message at the beginning of history changed to "scroll up to load more chat history..." (I remember it was saying something different, but I cannot reproduce the original message even if change the setting back to 1 day). Scrolling up doesn't change anything though (more history is not loaded)

https://share.conversations.im/belkka/i8mso7TojnBcyuyw/2808ca78-2543-40a5-83c6-a3b900e63154.png

`gajim --version` is 1.9.1 (recently upgraded from `gajim` to `gajim-git` in AUR)

As said you cannot load messages before your first join ✏

threshold is only respected for subsequent joins

setting no threshold for a public MUC is problematic

this could mean if you join this chat in a year, it will load one year of messages, with no way to stop it for you

so "join" here is not "user joins a MUC", but "client joins a MUC"? Can I fix it by leaving and joining chat (so that updated setting is applied)? Also, is message misleading or am I doing "scroll up" wrong?

Number of participants in this chat is changing between 356, 357 and 355... looks like someone is testing my idea XD

or there is something I do not understand about the protocol, because those numbers change too much in real time

> this could mean if you join this chat in a year, it will load one year of messages, with no way to stop it for you isn't "partial on-demand history loading" implemented in Gajim? The message ("Scroll up to load more chat history…") suggests that it's supposed to be implemented (exept it doesn't work for me). I'd like history to be only loaded when I scroll it ↺

im trying to tell you, that you *cannot* get history before your first join - no workaround whatsoever will make it possible

most mucs offer weblogs, which you can find in the information dialog

"scroll up to load more history" means loading it from your local database

not from the server

> im trying to tell you, that you *cannot* get history before your first join - no workaround whatsoever will make it possible but I *can* in other client. Namely, "Conversations" on Android ↺

yes, not sure how this is relevant here

are you thought i say its technically not possible, thats not what im saying, im saying you cant with current Gajim

so it's some kind of protocol extension that Gajim doesn't support?

lets say the protocol does not allow that to be implemented easily, we found no way of doing it without having ordering problems with messages

so we opted not do it until now

> im trying to tell you, that you *cannot* get history before your first join - no workaround whatsoever will make it possible wait, but what does threshold do then? > threshold is only respected for subsequent joins I interpreted this as "if threshold value is A and I join chat ONE, then I can see history up to A days before I joined. If I then change threshold value to B and (subsequently) join chat TWO, then chat TWO uses value B, but chat ONE is still using value A, because I joined chat ONE *before* changing threshold value" ↺

it means how much message is loaded on all joins except your first one

if you join a chat, leave it and join it 2 weeks later again, Gajim looks at the threshold and loads as much messages as it says

no threshold meaning, everything you missed between your first and second join

which for a public MUC with theoretically infiinte messages could be very much

for private MUCs the threshold is by default "no", so you will not miss any messages from your friends

for public MUCs its by default a day

> if you join a chat, leave it and join it 2 weeks later again, Gajim looks at the threshold and loads as much messages as it says got it, "subsequent joins after the first join in the same chat" ↺

belkka, you showed the "Default" setting

i would not touch that

you can change the setting per MUC

CTRL + I -> Settings

raise it only for public MUCs, where you think you need to read every message every day

i realize this is all a bit complicated and not very user friendly, but currently the best compromise we have ✏

> belkka, you showed the "Default" setting btw, as I understand from your explanation, the default setting that I've seen was only "default for public chats". Is there a separate "default for private chats" somewhere? ↺

no, because we think there is no reason to ever set a threshold for private chats

private chats have very few members <10

and very few messages

it is not problem to load months of history

but there are public MUCs with > 3000 people in it

there can be a 1000 messages per day

if you dont join a month, this can be very bad without threshold

To clarify: does XMPP "join" mean same as IRC join (every time I turn on my computer and run the client it's a new join to every chat I'm participating in)?

yes

good thing I've recently learned to use IRC, so that I could understand this terminology :) Do I get it correctly that list of chat (group) participants (at the right of Gajim interface) only shows people *online* (i.e. running their computer and client at the moment)? In other words if they all shut down their computers at the same time, the participants list will be empty for me.

Yes

private chats can have real fixed members, but we dont show the list, thats something we work on though, so its more like a whatsapp group where you can see who is part of it

and because everyone uses mobile clients like conversations

essentially nobody every "leaves" a chat anymore

because one device is at least online all the time

for private mucs we definitly want to offer a better solution, fixed member list that you can always see.

for public mucs i would argue there are so many people its not that important

Are private/public MUCs different at protocol level or client (Gajim) level? I was reading https://docs.modernxmpp.org/rationale/#types-of-groups recently, it mentions > From a protocol perspective this distinction is unnatural... How can I understand what MUCs are private in Gajim's UI? I believe I joined multiple public mucs, including this one. And I've also created a MUC for testing, which I "consider" private; it's rather a SUC (single-user chat) though, because I have no friends in XMPP.

Sometimes when I scroll the chat list to the bottom, then open a chat then grab the scrollbar and try to drag it upward, or use my scroll wheel, the chat list view will scroll but the the scrollbar remains frozen at the bottom. Is this a gtk issue?

belkka, in the information dialog there is a manage tab, you can configure a MUC there, if the muc is configured for "members-only" its effecitvely private

it means only people you invite can join, an no one else

a public muc is a muc where everyone also without invite can join

I'm on ubuntu 23.10, gnome, gajim nightly flatpak, and I keep experiencing that messages that should cause a desktop notification (the floating icon) don't, but it seems to always change the tray icon as it should. It could be unrelated to gajim. I don't know how to debug it. And it seems to alternate between creating or not creating a notification.

> Sometimes when I scroll the chat list to the bottom, then open a chat then grab the scrollbar and try to drag it upward, or use my scroll wheel, the chat list view will scroll but the the scrollbar remains frozen at the bottom. Is this a gtk issue? Wow, I have just observed this behavior as you described, but I cannot reproduce it consistently. I've noticed that there was one chat with new messages arrived while I was trying to follow your instructions. Maybe the issue is related to scenario when new messages appear and some chat *moves* to the top of the list. ↺

> Wow, I have just observed this behavior as you described, but I cannot reproduce it consistently. I've noticed that there was one chat with new messages arrived while I was trying to follow your instructions. Maybe the issue is related to scenario when new messages appear and some chat *moves* to the top of the list. sounds like it could be an issue ↺

but i dont understand why you need to scroll to see a chat with new messages

> Wow, I have just observed this behavior as you described, but I cannot reproduce it consistently. I've noticed that there was one chat with new messages arrived while I was trying to follow your instructions. Maybe the issue is related to scenario when new messages appear and some chat *moves* to the top of the list. Ah, you might be right with the icon sorting thing. I too am not able to consistently reproduce it, but I noticed this weeks ago and it did seem to be related to viewing chats with unread messages. ↺

> but i dont understand why you need to scroll to see a chat with new messages It happens and I haven't really been asking myself that. I'm thinking the sorting is delayed sometimes but maybe it also isn't happening at all sometimes ↺

we dont sort while you are over the list with your mouse

I don't have an easy way to test this, but I'll try later when this chat gets pushed down in the list ✏

I don't have an easy way to test this, but I'll try later when the chat gets pushed down in the list ✏

lovetox pushed 1 commits to branch gajim/master imprv: Don't check for updates if running from MS Store - https://dev.gajim.org/gajim/gajim/-/commit/77ca38424d4fa31db0ecad2c531735aad43b9724