Gajim - 2023-09-29

lovetox: a person from GNOME shell matrix room said that this issue is due to running Gajim from a python venv and not having it installed. Because for `Gio.Notification` to work the app needs to have a valid desktop file.

as per https://developer.gnome.org/documentation/tutorials/notifications.html#prerequisites

Now I'm perfectly confident I don't run a desktop system lol. It intentionally does not respect many of that FreeDesktop stuff.

gajim got rizz

I don't think I have that issue on gnome

ru on gnome 45

I'm on GNOME 42.xx

how ru runnging

gajim?

kurion: BTW gajim doesn't support D-Bus activation

> umu: how ru runnging from a venv, with `./launch.py` ✏

How do I remove a old disused not connected account. I can remove existing accounts but not this old one

Why do you think you can't remove it ?

Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: *442328c2* < https://dev.gajim.org/gajim/gajim/-/commit/442328c20ca0bf15914b9aa1387d87271260c998 > feat: Display status message in banner

I had changed servers but the old account was still showing, I found that when I rebooted PC , not just turning Gajim off/on it then allowed me to remove the account ✏

I had changed servers but the old account was still showing, but not connected. I found that when I rebooted PC , not just turning Gajim off/on it then allowed me to remove the account ✏

lovetox: it's been buried below my attempts to place idle time somewhere, but I think https://dev.gajim.org/gajim/gajim/-/merge_requests/972 is less controversial and fixes something very useful for adhoc commands. Since you accepted the "execute command" menu item in all chat banners, it would make sense to make adhoc commands fully functional. I added 2 screenshots of what it looks like now. I think is is OK, even if using XEP-0122 to improve formatting of typed fields would be nice, but this could be for the next MR ;-)

nicoco, yes im not opposed to reporting forms

i look into the MR

about the whole presence info thing

i want to refactor this a bit i think we go down a wrong path

show, status message, idle are part of a single presence, all those infos should be always shown together

what we did now is applying different logic to status, show and idle

basicially mixing data from different presence together, i think this is not good and will lead to weird results, like someone who is available, but at the same time idle, and has a away status message

Hum I was wondering about that too.

It's already the case FWIW.

it was not the case until now

Yes it it. When I put my phone in "dnd", cheogram sets its presence show to "dnd" and I appear "dnd" in gajim. Even though I'm "available" on gajim.

how is this mixing data?

The "circle" next to my avatar is dnd

There is logic to decide that "one resource dnd" means "contact is globally dnd"

yeah its not mixing, its i have 2 presence and i decide to show data from only one

vs i have 2 presence and pick random data from each of them and show them

Aren't priorities useful here?

Granted, it's not exposed easily in any modern client.

no, nobody uses them

yeah

priority is a dead concept

its from a time where MAM and Carbons did not exist

and message routing was done with priority

i think deciding based on show is much more useful

OK. Still, I fail to see why the logic of deciding "cheogram dnd, gajim available → contact dnd" is very different from picking up one status message.

if you want to get even more fancy, you can do it by some kind of activity marker

Also, I believe that different status messages from different clients is very rare in practice

The reason I mention this dnd having priority over other statuses is also because I don't think it's great. To me, 1 resource dnd, 1 resource available should translate to "green circle next to my avatar". But I agree it's debatable.

Maybe the circle sould be split, like a pie chart ✏

It sounds a bit ridiculous, but I kindof like the idea lol

i doubt any users needs that, i would never need that

the goal is to get away from presence, not expose it even more to the user

or not presence, but rather presence per device

Agreed. Resource name != device or app name though. But with disco info we get the client or the type of device, maybe?

i never heard a convincing argument why someone needs to be dnd on a device, but available on the other

Yeah it's just me misusing the 'dnd' feature of my phone I guess.

i always saw it the other way around

I should put in on silent instead, but it's with dnd on android it still rings when my wife calls, which is basically all I need. Besides that I _never_ want my phone to make a single sound.

say you have your smartphone with you, and you set it to DND, because you really dont want to be disturbed, and you let your contacts know you wont respond

would be nice, to make you run to every other device first and set everywhere dnd

and only THEN your contacts know your dnd

this would practically never happen

Yeah, probably. Anyway, I wasn't even thinking about changing that. Getting back to status messages, you don't like the "single status in banner" after all?

Or, more precisely, you want to pick the status based on show instead of priorities?

if i show multiple data from presence, it should be all from the same

its even more ridicoulus with idle

yeah that's why the logic I implemented is "if a device is available, we don't show idle"

what speaks against, simply deciding for a presence, instead doing some logic for each attribute of a presence

if you are available, i dont want to show idle or show = away for another device, or the away status message

all these things are always bound to show if you think about it

idle makes only sense with show= away/dnd

status message is often also changed depending on show

…by gajim :)

I don't think any other maintained client do that, "Idle because…"

maybe I'm wrong

its a option in gajim nobody forces you to set a away status message

Oh OK.

What about this: the tooltip should display all presences from all devices.

status in presence is of course not nice, it would be much better in pubsub

With their respective show, idle since, status

gajim is an "advanced client" after all :)

we do that already in the roster

Yup, let's just use this tooltip on avatar hover everywhere then?

yes but thats another topic

OK.

i mean the status message in the banner is still nice

it just should be the one that fits to the show value

at least as long until we have status message in pubsub

Hello all! i am new here and was wondering how to get the pgp plugin to work?

Linuxhelptipsxmpp, do you have it installed?

nicoco: I'd like to explore popovers on avatars, which expose presence info but also clickable actions. Maybe that's useful

lovetox: so basically, copy the logic from `BareContact.show` to `BareContact.status`

no i think thats also bad, usually when we show something we show multiple attributes, would be bit ugly if we ran the algo everytime a attribute is accessed

but i just think about this, i have an idea

cal0pteryx: I just played around trying to see how GTK3 works, make us something nicer and close my MR :)

> would be bit ugly if we ran the algo everytime a attribute is accessed sure, so we run it once and cache the selected presence, and invalidate the cache value `on_presence()`?

@lovetox yes

> bodqhrohro a écrit : > Now I'm perfectly confident I don't run a desktop system lol. It intentionally does not respect many of that FreeDesktop stuff. desktop is not defined by whether it's unfreedesktop or not