jdev - 2021-02-01

jonas’: I've heard that you wrote xep 0392 and implemented it in poezio, isn't it?

paul, both correct!

I have a color issue, following the xep I have different color from poezio, and reading the poezio code I see that when computing the hue_angle the sha output is / 65535 instead of 65536 in the xep

that is a typo in the poezio source then

the XEP has the correct value

ok thanks :)

(logic behind it: as the result is supposed to be an angle, 0 == 360. Hence, we don’t want to be able to generate *both* 0 and 360. Hence, we must divide by 2^16 instead of 2^16-1 in order to get the full possible range of distinct values out of the 16 bits of hash)

paul, thanks for the hint, I shall patch it

make sense, you are welcome for the hint

a few days ago i asked if there is a client that stores notifications in a way they survive a restart

does someone know such a client? is there any one that thinks this is important for a client?

or can we live with seeing 0 notifications after restart

Psi will store unread message counts, if that's what you mean.

yes its a subset of what i mean, but yes thats probably the most important notification

i wonder what i should store, simply a dict like thing like "contact: 10 notifications"

or does the user need to know exactly which 10 messages are unread

i could probably store the stanza or message id

Psi stored the messages.

but then it gets much for mucs ect, if i have to store 350 unread messages with message id etc in a public muc

Of course, I've not looked at the Psi code for coming up to a decade and a half, so I may be a *smidge* out of date.

yeah maybe i take a look myself

Gajim shows me a little unread marker when I start it if that's what you mean? Or do you want it to pop up notifications again for each message?

actually this sounds like "inbox"

yes Sam Whited , i mean exactly that, right now Gajim saves one db row for every unread message but only 1:1

and yes jonas’ its probably that if we talk about syncing this state across clients

but i rather try to think how i can solve this locally

i just wonder if and how this saving of unread messages scales in public mucs

lovetox, one row per message? as opposed to one row per chat, with a pointer to the latest message?

Some clients have notification setups. None, mentioned, always. In big public mucs I have just mentioned. I would recommend to do this based on the notification setup.

🤔

What Zash said. Although I still don't get what you're asking or what you're trying to do I think.

Sam Whited, you have 1134 messages unread in jdev, your computer does a restart

what do you expect to see when you start it again

lovetox, I think I don’t expect a notification for those, but the unread counter in the UI should be correct.

lovetox: the chat marked however you mark unread (maybe it's bold, maybe it has a little icon, an unread number, whatever) and when I open it there's a line dividing the read from the unread and it's at the top of the unread list.

but I *do* expect a notification for messages which arrived between the last focus to gajim and the restart, I think.

1134 unread messages + new as counter. I think conversations does.

I wouldn't expect any notifications after restart (assuming you mean some sort of pop up) personally.

ok so i need to save the counter, and the last message-id, and if you open the chat again, i scroll to that message-id and thats it

Sam Whited, torn on that one, I think no notifications is OK

sorry with notification i mean a bubble with the counter

not a desktop notification

yeah, those need to be correct

oh gotcha, yah, I'd show an icon or a counter or something

ok and when you focus the chat, and i scroll to that message, should the counter go to 0?

I personally think there’s no good solution to *that* specifically. All solutions are terrible / wrong. ✏

i mean i can color all messages in a way so you know they are unread

but when i the point where i mark them read

On a desktop client at least I'd expect it to go to zero once I've scrolled to the bottom. That's what Slack does and it seems to work pretty well.

but IME the solutions which allow me to mark as read as easily and painlessly as possible are the least worst

Or once I click the "Clear notification" or "Jump to recent messages" or whatever if either of those are a feature you hvae

im in the process of rewriting the whole thing, so thats why i ask

reaching bottom is good i guess

but with that solution i dont need to save all message-ids, only the first unread

and the total count

It also depends if you have threads, I think. Those may change things.

no i dont have threads

and i will not

personally i hat them

Cool, no need to handle those differently then

Yah I haven't seen a threading implementation I like. I want them, I like the general idea, I just don't like any of the implementations I've tried. Slack is the least-bad I think, but it's the only one I've used in a long time so I may just be used to the pain.

Sam Whited, out of curiousity, did you try zulip?

(a recent one, they had a major release in 2020)

we had a zulip trial run at $dayjob, and I was pleasantly surprised. threads feel really natural and workable there.

Slack's looks ok on the surface, but then you realise that threads are invisible as soon as you don't choose 'share in main channel' or whatever it's called, and you don't see replies, and blah. I agree it's probably the least-bad, mind.

jonas’: I think so, but I literally don't remember it. That sounds really familiar though. Definitely didn't try it in 2020, so maybe I'll play with it again

My favourite threading implementations are the ones that just allow replies to messages, rather than 'threads'.

Kev: I really like that they're invisible actually and that I can get to them from the initial message and from the "Threads" view, I just wish they had a subject to make them more obvious and you could see a list of threads by channel

Different use case, I guess.

I like it because I end up discussing a feature I'm working on in our team channel, and some front end people end up discussing some front end stuff I don't care about, and neither of us have to get every channel notification, it's just kind of hidden away for people who want that conversation to look at